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.