Seven sequential quality gates.gates Each— each job declares needs on the previous one.

Triggers and Concurrency Control

The workflow listens to push and pull_request events on main/master, and includes workflow_dispatch for manual runs. Concurrency settings prevent duplicate branch runs by canceling outdated executions. On protected branches, teams often keep in-progress runs intact to avoid partial deployment states.

Typical use of workflow_dispatch: hotfix redeployments, reruns for a specific commit, and operator-controlled release execution.

Global Environment Variables

env:
  NODE_VERSION: '20'                 # defined once and reused by all jobs
  DOCKER_IMAGE_NAME: gocart          # consistent image naming across stages
  NEXT_PUBLIC_CURRENCY_SYMBOL: '$'   # region-configurable app-level setting

Centralized variables reduce repetition and lower the risk of drift. For example, changing the Node runtime in one place updates every job that depends on it.

Build Stage: Reproducibility and Artifact Handoff

- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: ${{ env.NODE_VERSION }}
    cache: npm                         # avoids re-downloading unchanged packages
- run: npm ci                          # exact lock-file install for reproducibility
- run: npm run build                   # compile Next.js and generate .next output
- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: .next/
    retention-days: 1                  # short-lived handoff between jobs

npm ci installs exactly what the lock file defines, which keeps builds deterministic across environments. Since jobs run on fresh runners, artifacts are used to hand off build output to later stages.

Lint and Test Stages: Quality Gates with Diagnostics

The lint stage enforces coding standards and catches static issues early. The test stage runs the automated suite with verbose reporting. Both stages publish logs using if: always(), so failure data is retained for troubleshooting and audit trails.

Security Stage: Visibility-First Governance

The security stage usually combines dependency auditing and secret-pattern detection. Dependency checks identify known CVEs; secret scanning looks for leaked credentials such as API keys and passwords. Together, these checks improve release confidence without relying on manual inspection.

In many enterprise teams, findings are reported and retained for compliance review, while remediation is prioritized based on severity and business impact.

Docker Build and Conditional Push: Governance in YAML

# Docker Build validates the image, but does not push on pull requests
- uses: docker/build-push-action@v6
  with:
    push: false                       # build-only on PR branches
    tags: gocart:test
    cache-from: type=gha              # layer caching shortens repeated builds
    cache-to: type=gha,mode=max

# Docker Push runs only for approved execution paths
if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'

This condition enforces a critical policy: pull requests validate code, but do not publish release images. Credentials are injected through encrypted repository secrets and are never stored in plain text in workflow files.

Release Stage: Automated Versioning and Traceability

For successful main-branch runs, release automation can generate semantic tags and publish GitHub Releases with generated notes. This gives teams clean version history, commit-level traceability, and faster rollback capability.