A team of 8 ships a Node API to EKS in ap-south-1 through Argo CD, which syncs a separate GitOps repository. Today a deploy.sh on a laptop builds the image with long-lived AWS keys, tags it latest and runs kubectl set image. Write one GitHub Actions workflow that tests on a Node matrix with caching, builds once with Buildx and a registry layer cache, logs in to ECR through OIDC, pushes the image tagged with the git SHA, scans it with Trivy, deploys to staging by opening a PR in the GitOps repo with the image digest, and deploys to production only from a v* tag after required reviewers approve.

File: .github/workflows/ci-cd.yaml

Triggers -> jobs that run:
  pull_request (same repo)   test, build (no push)
  pull_request (fork)        test only
  push main                  test, build, scan, deploy-staging
  push tag v1.4.2            test, build, scan, deploy-prod (pauses for approval)

Job outputs:
  build.outputs.image    123456789012.dkr.ecr.ap-south-1.amazonaws.com/shop/api
  build.outputs.digest   sha256:3f0c...  (from docker/build-push-action outputs.digest)

Action inputs used (checked against each README on 2026-11-03):
  aws-actions/configure-aws-credentials  role-to-assume, aws-region, role-session-name
  aws-actions/amazon-ecr-login           outputs.registry
  docker/build-push-action               context, push, tags, labels, cache-from, cache-to,
                                         provenance; outputs.digest
  aquasecurity/trivy-action              scan-type, image-ref, format, severity,
                                         ignore-unfixed, exit-code
  actions/setup-node                     node-version, cache, cache-dependency-path
  peter-evans/create-pull-request        token, branch, commit-message, title, body

Repository settings the workflow relies on:
  Secret GITOPS_TOKEN        fine-grained PAT or GitHub App token for the gitops repo
  Environment staging        no protection rules
  Environment production     required reviewers (1 of up to 6), deployment rule: tags v*
  IAM role trust policy      token.actions.githubusercontent.com, sub = repo:org/api:ref:refs/heads/main
                             and repo:org/api:ref:refs/tags/v*

Inputs the workflow reads:
  github.sha           40-char commit; the image tag
  github.ref           refs/heads/main | refs/pull/12/merge | refs/tags/v1.4.2
  github.ref_name      main | v1.4.2
  github.event_name    push | pull_request
  secrets.GITOPS_TOKEN scoped to the gitops repo only

ECR repository shop/api after one push to main:
  shop/api:<sha>         the image, also addressable as shop/api@sha256:<digest>
  shop/api:buildcache    BuildKit cache export (mode=max: every stage's layers)

GitOps repo layout Argo CD watches:
  envs/staging/api/deployment.yaml   image: <registry>/shop/api@sha256:<digest>
  envs/prod/api/deployment.yaml      same line, changed only from a tag run

Job graph:
  test (matrix 22, 24) -> build -> scan -> deploy-staging   (main)
                                        -> deploy-prod      (tags, environment gate)

1. Put permissions: contents: read at the top so every job starts with a read-only GITHUB_TOKEN; build and scan add id-token: write because only they request an OIDC token.
2. Set concurrency.group to workflow plus ref. cancel-in-progress is an expression that is true for branches and PRs and false for tags, so a release never dies half way through a push.
3. test runs the matrix with fail-fast: false so a failure on Node 22 still shows the Node 24 result; setup-node with cache: npm restores ~/.npm keyed on the lockfile hash.
4. build checks out with persist-credentials: false, exchanges the OIDC token for 1-hour AWS credentials, logs in to ECR, and starts a Buildx builder. build-push-action builds with cache-from and cache-to pointing at a buildcache tag in the same ECR repository, pushes shop/api:<sha> when the event is not a pull request, and writes the content digest to steps.push.outputs.digest, which the job re-exports.
5. scan logs in again (each job is a fresh runner) and runs Trivy on image@digest. exit-code: 1 with severity: CRITICAL and ignore-unfixed: true fails the job on critical findings that have a fix, which is the rule most teams can enforce today.
6. deploy-staging runs only on main, checks out the GitOps repository with a token scoped to it, rewrites the image: line in the staging overlay to image@sha256:... with sed, and opens a PR with peter-evans/create-pull-request. Argo CD syncs after merge; the workflow never touches the cluster.
7. deploy-prod runs only on v* tags and declares environment: production. GitHub pauses the job until a required reviewer approves, then the same digest is written to the prod overlay and a PR is opened.
8. Every uses: is a full commit SHA with # vX.Y.Z after it, read from the action's release page, so a moved tag cannot change what runs.

OIDC instead of stored keys

A stored AWS_ACCESS_KEY_ID is valid until someone rotates it, readable by anyone with admin on the repository, and shows up in audit logs as a user, not a workflow. With OIDC, each job asks GitHub for a signed JSON Web Token that says which repository, ref and workflow is running, configure-aws-credentials sends it to sts:AssumeRoleWithWebIdentity, and AWS returns credentials that expire in 1 hour (role-duration-seconds, 900 to 43200). The IAM role's trust policy checks the token's aud (sts.amazonaws.com by default) and sub, so you can allow repo:org/api:ref:refs/heads/main and ref:refs/tags/v* and nothing else, which is why a fork PR cannot push even if the job ran. The workflow needs id-token: write, and that is the only permission beyond contents: read any job asks for. Secrets in this design: one, the GitOps token, and it is scoped to one repository.

Build once, deploy by digest

A tag like latest or even v1.4.2 can be re-pushed to point at a different image; a digest is the SHA-256 of the manifest and cannot. The build job exports outputs.digest, scan pulls that digest, staging pins that digest, and production pins the same one after approval. Nothing is rebuilt between environments, so "it passed in staging" means the same bytes. The GitOps repo holds image@sha256:... lines, which also makes git log a complete deployment history and git revert a rollback. The registry cache is the other half of "build once": cache-to with mode=max exports every stage's layers (not only the final stage, which is min) to a buildcache tag, and cache-from on the next build imports it, so a code-only change re-runs only the stages after COPY src. When the cache tag does not exist yet the import step fails but the build continues, so the first run is simply cold.

pull_request_target and fork pull requests

pull_request from a fork runs with a read-only token and no secrets, which is safe. pull_request_target runs in the context of the base repository with secrets and write permission, and if it also checks out the PR's head, the fork author's code runs with your secrets: that is how repositories get their tokens stolen. This workflow uses plain pull_request, and the build job's if: additionally skips fork PRs so the OIDC step never runs for them. If you need to comment on fork PRs with a privileged token, use workflow_run after the untrusted workflow finishes, and never check out untrusted code in the privileged one.

Environments as gates, and the caching strategy

An environment is a named target with its own secrets and protection rules: required reviewers (up to 6, one approval is enough, with an option to block self-review), a wait timer, and a rule restricting which branches or tags may deploy. Declaring environment: production on a job pauses it until the rules pass and records who approved. That is the whole production gate: no custom approval logic in YAML. Two caches do different jobs here: setup-node's cache restores ~/.npm on the test runner so npm ci is fast, and the registry cache stores image layers so the Dockerfile's deps stage is a hit. type=gha cache is the alternative for the second; it is simpler but limited in size per repository and evicted after 7 days of no use, so the ECR-hosted cache is the better fit for a repository that builds daily.

Tests. Push a branch and open a PR: test runs twice, build runs without push, scan and the deploy jobs are skipped. Open the same PR from a fork: only test runs. Merge to main: a PR appears in the GitOps repo with an image@sha256: line, and the ECR repository has shop/api:<sha> and shop/api:buildcache. Push a second commit to main within a minute: the first run is cancelled. Push v1.4.2: deploy-prod shows "waiting for review" and proceeds only after approval; the digest in the prod PR equals the one in the run's build output. Plant a known-critical package in a test branch and confirm scan fails with exit 1.

Edge cases. First build with no buildcache tag: the cache import warns and the build proceeds cold. A tag pushed on a commit that already built from main builds again (different ref, different run); strong answers reuse the digest by looking it up with aws ecr describe-images instead. The sed edit fails silently if the image: line format changes; git diff --exit-code after the edit catches a no-op. GITOPS_TOKEN expiry breaks both deploy jobs at once; a GitHub App token avoids expiry.

What a strong answer adds. Pinning actions by SHA and explaining why; persist-credentials: false; reading the Buildx mode=max default; provenance and SBOM attestations with cosign signing of the digest; timeout-minutes on every job; and the honest statement that deploy-prod here opens a PR rather than merging it, so a second person reviews the diff that Argo CD will apply.

• Tag moved on an action. A compromised v4 tag runs attacker code with your OIDC token. Mitigation: pin by full SHA, bump with Dependabot, review the diff.
• Fork PR gets secrets. pull_request_target plus checkout of the head ref. Mitigation: use pull_request, skip fork PRs in privileged jobs, and keep permissions minimal.
• Production deploys a different image than staging. A rebuild on the tag produces a new digest. Mitigation: deploy by the digest from the build output, and prefer looking up the existing digest for the commit.
• Cancelled release. cancel-in-progress: true kills a tag run after the push but before the PR. Mitigation: the expression that disables cancellation for refs/tags/.
• Trivy blocks every deploy. A critical CVE with no fix in the base image stops all releases. Mitigation: ignore-unfixed: true, a .trivyignore with an expiry date, and a base image bump.
• GitOps token with too much scope. A classic PAT with repo on every repository. Mitigation: fine-grained PAT or GitHub App token limited to the gitops repository, contents and pull-requests write only.
• OIDC trust policy too wide. sub condition of repo:org/* lets any repository in the org assume the deploy role. Mitigation: list the exact repository and refs in the condition.
• Cache poisoning. A PR run writes layers into the shared buildcache tag. Mitigation: only push cache from main and tags; PRs read it but do not write.