GitHub Actions (or GitLab CI) is great for Continuous Integration (CI). However, using it for Continuous Delivery (CD) isn’t necessary. There are downfalls to it.
A CI platform is where all the developers collaborate. It is where the code is compiled, linted, and tested. This process requires use of a lot more third-party dependencies than the release process. The CI platform needs read access to the source code. It might read-access to more repositories but almost never a write access.
A CD platform requires release related credentials. It will almost certainly need write access to maintain some release information like branches or tags. Fewer people need access to this. Even fewer third-party dependencies are required for this process.
Commingling the two system drastically impacts the security surface. This is what caused a compromised release of UltraAnalytics . The same attack vector was involved in compromise of tj-actions/changed-files which impacted 23,000 GitHub repositories. And last week, even GitHub’s own CodeQL was compromised and the attacker had the ability to compromise thousands of repositories using Code QL.
Using a separate release platform drastically reduces the attack surface.
A secondary benefit is efficiency. Deployment artifacts like Docker images can be big. Especially, for interpreted languages like Python and TypeScript.
So, here’s a better approach for continuous delivery.
Use your cloud platform’s native solution like AWS CodeBuild or Google Cloud Build . These products will be notified whenever your code on the master/main branch changes and will build the Docker binaries in the cloud.
GitHub won’t have access to your cloud deployment. And AWS/Google Cloud can pull source code from GitHub via GitHub Applications, so, no more pesky secrets that can potentially leak.
Further, this adds a separation of concerns. The where and how of the service deployment happens belongs to the cloud platform. And the source control hosting service need not be aware of it.