GitHub Actions
GitHub Actions is the CI/CD system built into GitHub. Every change to the platform reaches AWS through it: infrastructure is planned on pull requests and applied on merge, container images are built once and promoted by tag, and secrets are synced on merge. There is no other deployment path.
What it does
A workflow is a YAML file under .github/workflows/ that runs jobs on a trigger: a pull request, a push to main, a release, a schedule or a button. Jobs run on GitHub-hosted runners or on runners you host. GitHub Environments add protection rules, such as required reviewers, and hold per-environment variables.
How BuiltForProd uses it
| Repository | Workflows | What they do |
|---|---|---|
acme-aws-platform-baseline | plan.yml, apply.yml, drift-detection.yml | Lint and scan, then terragrunt run --all plan across every account on a pull request; apply on merge, gated by the prod Environment; scheduled plans that open an issue when drift is found (critical accounts Tuesday to Friday, all accounts on Monday) |
acme-aws-blueprint-webapp-infra, acme-aws-blueprint-etl-infra | plan.yml, apply.yml | The same per stage, as a matrix of dev, staging and prod whose jobs start in parallel, each in the GitHub Environment of that name; prod holds the required reviewers |
acme-aws-blueprint-webapp-code | ci.yml, cd-integration.yml, cd-release.yml, promote-prod.yml, cd-frontend.yml | Lint, test, build and Trivy-scan on pull requests; build once and push main-<sha> on merge; add the release tag on a GitHub Release; open GitOps pull requests per stage; build and publish the front end |
acme-aws-blueprint-etl-code | ci.yml, cd-integration.yml, cd-release.yml | The same for the Lambda image and the Glue script, deploying dev on merge and staging then prod on release |
acme-aws-blueprint-secrets | plan.yml, sync.yml | Validate and dry-run the secret sync on pull requests; decrypt and write to Parameter Store on merge |
Some conventions hold everywhere. Every action is pinned to a commit SHA. Plans post their output as a pull request comment. Applies are serialized by a concurrency group and never cancelled; a newer plan supersedes an older one. Workflows authenticate to AWS through GitHub OIDC and hold no keys. The web application's three rollout workflows share one composite action, .github/actions/gitops-pr, which opens a pull request in the GitOps repository with a short-lived token from the acme-runner GitHub App.
Runners are GitHub-hosted by default. Setting the repository variable RUNNER_LABELS moves the infrastructure jobs to ephemeral self-hosted runners in the automation account, created by the github-runner unit from the registry module github-aws-runners/github-runner/aws 7.11.0: Spot instances that start on a workflow_job webhook, run one job and terminate. They are needed only when the EKS public endpoint is switched off.
Terms you will see
| Term | Meaning |
|---|---|
| Workflow | One YAML file with its triggers and jobs. |
| GitHub Environment | A named target with protection rules and variables, such as prod with required reviewers. |
| Matrix | A job run once per value, here once per stage in the blueprint infrastructure repositories. |
| Composite action | A reusable step sequence, such as gitops-pr. |
| Self-hosted runner | A machine you provide to run jobs, here ephemeral EC2 in the automation account. |
Where to read more
- GitHub OIDC for how workflows get AWS credentials
- GitOps and environments and promotion for the delivery model
- Drift for the scheduled plans