Build a Full CI/CD Pipeline: Test, Scan, Deploy

You will build an end-to-end pipeline that tests, builds a container, scans it, and deploys on a successful merge to main. By the end every release is automated, gated, and traceable to a commit.

This lab chains together everything from the earlier GitHub Actions and Docker labs into a single production-style workflow. A commit or pull request triggers the test stage; only green tests build a container image; the image is pushed to a registry and scanned for critical vulnerabilities; and only a clean scan on the main branch is allowed to roll out to the cluster. Each stage passes or fails the whole run, so a broken build or a vulnerable image can never reach production silently.

The pattern you build here is the same one used in real teams: fast feedback for developers (tests in under a minute), a supply-chain gate (vulnerability scanning), and a controlled blast radius (deploy only from the protected default branch). Everything is defined as YAML in the repo, so the pipeline itself is versioned, reviewed, and auditable like any other code.

Architecture Overview

The pipeline is a directed chain of jobs. Each job runs in its own runner and only starts when the previous job succeeds, because of the needs: keyword. The scan is the security gate: a critical finding flips the run to failed and the deploy job never starts.

Two conditions guard the deploy stage, and both must be true: the scan job must have passed (enforced by needs: scan) and the workflow must be running against the main branch (enforced by an if: condition). Pull requests run the test, build, and scan stages only, so reviewers see security feedback before merge without any risk of a preview branch reaching production. On pull requests the registry push is skipped (fork tokens are read-only) and the built image reaches the scan job as a workflow artifact, so the same immutable artifact is still what gets scanned.

How It Works

Environment Setup

You will need: GitHub Actions, a container registry, Trivy, and a deploy target (kubectl/SSH).

Before you begin: store registry and deploy credentials as GitHub secrets.

Concretely, this lab uses GitHub Container Registry (ghcr.io) as the registry and a Kubernetes deployment named app as the target. Install the CLI tools locally so you can verify every stage from your terminal as well as in the Actions UI:

INSTALL THE CLI TOOLS (macOS)

brew install gh trivy kubectl
gh auth login        # authenticate the GitHub CLI
kubectl version --client
trivy version

Secrets must never live in the workflow file. Create them once with the GitHub CLI (or under repo Settings › Secrets and variables › Actions) and reference them as ${{ secrets.NAME }}. The pipeline needs exactly one secret: a kubeconfig that can update the deployment. Registry pushes use the built-in GITHUB_TOKEN with a job-level packages: write permission, so no long-lived personal access token is created or stored anywhere.

STORE THE PIPELINE SECRETS

STORE THE KUBECONFIG SECRET (BASE64-ENCODED)

# Base64 keeps the multiline kubeconfig intact through the secrets transport;
# the workflow decodes it with: echo "$SECRET" | base64 --decode
base64 -w0 ~/.kube/config | gh secret set KUBE_CONFIG_B64

gh secret list

Expected output of the last command:

KUBE_CONFIG_B64  Updated 2026-09-19

The repository layout is deliberately small, the pipeline, the app, its tests, and its Dockerfile all live side by side:

repo/
├── .github/workflows/cicd.yml   # the pipeline you are building
├── app.py                       # demo application
├── requirements.txt
├── tests/test_app.py            # pytest suite
└── Dockerfile                   # from the Docker Images lab

Common mistake: putting the workflow in .github/workflow/ (singular) or only on a feature branch, Actions only discovers workflows in .github/workflows/ on the default branch for push triggers to behave as expected.

Step-by-Step Execution

name: cicd
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read   # every job adds only the extra scopes it needs

concurrency:
  group: cicd-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.11', cache: 'pip' }
      - run: pip install -r requirements.txt
      - run: pytest -q

jobs:
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t ghcr.io/tyfsadik/app:${{ github.sha }} .

  build:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write   # scoped to this job; fork PRs still get read-only
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        if: github.event_name != 'pull_request'
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - run: docker build -t ghcr.io/tyfsadik/app:${{ github.sha }} .
      # Push only on trusted events: fork PRs receive a read-only token.
      - run: docker push ghcr.io/tyfsadik/app:${{ github.sha }}
        if: github.event_name != 'pull_request'
      # On PRs, hand the built image to the scan job as an artifact instead.
      - run: docker save ghcr.io/tyfsadik/app:${{ github.sha }} -o /tmp/app.tar
        if: github.event_name == 'pull_request'
      - uses: actions/upload-artifact@v4
        if: github.event_name == 'pull_request'
        with:
          name: app-image
          path: /tmp/app.tar
          retention-days: 1

  scan:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: read   # pull the pushed image on trusted events
    steps:
      # On trusted events the image was pushed; on PRs it arrives as an artifact.
      - uses: docker/login-action@v3
        if: github.event_name != 'pull_request'
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: actions/download-artifact@v4
        if: github.event_name == 'pull_request'
        with:
          name: app-image
      - run: docker load -i app-image/app.tar
        if: github.event_name == 'pull_request'
      - uses: aquasecurity/[email protected]
        with:
          image-ref: ghcr.io/tyfsadik/app:${{ github.sha }}
          severity: CRITICAL
          ignore-unfixed: true
          exit-code: '1'

ghcr.io/tyfsadik/app:9f2c1ab (alpine 3.19.1)
=================================================
Total: 0 (CRITICAL: 0)

┌─────────────┬────────────────┬──────────┬───────────────────┐
│   Library   │ Vulnerability  │ Severity │ Installed Version │
├─────────────┼────────────────┼──────────┼───────────────────┤
│ openssl     │ CVE-2024-0727  │ CRITICAL │ 3.1.4-r0          │
└─────────────┴────────────────┴──────────┴───────────────────┘
Error: Process completed with exit code 1.

  deploy:
    needs: scan
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    concurrency:
      group: production-deploy
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      - uses: azure/setup-kubectl@v4
      - name: Write kubeconfig
        run: |
          mkdir -p $HOME/.kube
          echo "${{ secrets.KUBE_CONFIG_B64 }}" | base64 --decode > $HOME/.kube/config
          chmod 600 $HOME/.kube/config
      - name: Roll out new image
        run: |
          kubectl set image deploy/app app=ghcr.io/tyfsadik/app:${{ github.sha }}
          kubectl rollout status deploy/app --timeout=120s

Complete Workflow File

The three steps above built the pipeline job by job. Here is the entire .github/workflows/cicd.yml assembled, so you can copy it in one piece and then read back through the annotations below. Note that the scan job also gets its own registry login, Trivy pulls the image from ghcr.io, and a private package requires authentication just like a push does.

FULL PIPELINE, .github/workflows/cicd.yml

name: cicd
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read   # every job adds only the extra scopes it needs

concurrency:
  group: cicd-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.11', cache: 'pip' }
      - run: pip install -r requirements.txt
      - run: pytest -q

  build:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write   # scoped to this job; fork PRs still get read-only
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        if: github.event_name != 'pull_request'
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - run: docker build -t ghcr.io/tyfsadik/app:${{ github.sha }} .
      # Push only on trusted events: fork PRs receive a read-only token.
      - run: docker push ghcr.io/tyfsadik/app:${{ github.sha }}
        if: github.event_name != 'pull_request'
      # On PRs, hand the built image to the scan job as an artifact instead.
      - run: docker save ghcr.io/tyfsadik/app:${{ github.sha }} -o /tmp/app.tar
        if: github.event_name == 'pull_request'
      - uses: actions/upload-artifact@v4
        if: github.event_name == 'pull_request'
        with:
          name: app-image
          path: /tmp/app.tar
          retention-days: 1

  scan:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: read   # pull the pushed image on trusted events
    steps:
      # On trusted events the image was pushed; on PRs it arrives as an artifact.
      - uses: docker/login-action@v3
        if: github.event_name != 'pull_request'
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: actions/download-artifact@v4
        if: github.event_name == 'pull_request'
        with:
          name: app-image
      - run: docker load -i app-image/app.tar
        if: github.event_name == 'pull_request'
      - uses: aquasecurity/[email protected]
        with:
          image-ref: ghcr.io/tyfsadik/app:${{ github.sha }}
          severity: CRITICAL
          ignore-unfixed: true
          exit-code: '1'

  deploy:
    needs: scan
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    concurrency:
      group: production-deploy
      cancel-in-progress: false
    permissions:
      contents: read
    steps:
      - uses: azure/setup-kubectl@v4
      - name: Write kubeconfig
        run: |
          mkdir -p $HOME/.kube
          echo "${{ secrets.KUBE_CONFIG_B64 }}" | base64 --decode > $HOME/.kube/config
          chmod 600 $HOME/.kube/config
      - name: Roll out new image
        run: |
          kubectl set image deploy/app app=ghcr.io/tyfsadik/app:${{ github.sha }}
          kubectl rollout status deploy/app --timeout=120s

A few lines deserve a second look before you commit this:

• on: push: branches: [main] plus pull_request: means PRs run the full test/build/scan chain for review feedback, while only merges to main reach the deploy job.
• The top-level permissions: block grants only contents: read. The build job adds packages: write and the scan job adds packages: read; no other job can touch the registry, so a compromised step holds the smallest possible token.
• The push is skipped on pull_request events because fork PRs receive a read-only token. The image is still built exactly once per run; on PRs it travels to the scan job as an artifact instead of through the registry.
• needs: appears on every job after test, which is what turns four independent jobs into a single gated chain. Remove one and that stage runs in parallel, breaking the gate.
• The same ${{ github.sha }} tag appears in build, scan, and deploy, one immutable artifact flows through the whole pipeline instead of being rebuilt at each stage.
• concurrency cancels superseded runs on the same ref, and the deploy job's production-deploy group (with cancel-in-progress: false) serializes production rollouts so two runs never race.
• The kubeconfig travels base64-encoded (KUBE_CONFIG_B64) and is decoded with base64 --decode, so multiline transport cannot mangle it the way a raw echo of the secret can.
• environment: production attaches the deploy job to a GitHub environment, which is where you later add required reviewers for a manual approval gate.

Validate the YAML before pushing, a syntax error in a workflow file fails silently until the next trigger, which is a frustrating way to discover a typo:

SANITY-CHECK THE WORKFLOW LOCALLY

python3 -c "import yaml,sys; yaml.safe_load(open('.github/workflows/cicd.yml')); print('workflow YAML OK')"
# workflow YAML OK

Progress So Far

All three stages are now wired together: tests gate the build, the build feeds the scan, and the scan gates the deploy. The remaining work is proving the whole chain behaves correctly, including its failure modes.

Testing & Validation

The latest run should be green and the deployment image tag should match the merged commit SHA, proving end-to-end traceability.

Validate the pipeline in both directions, the happy path and the gates. First confirm the happy path end to end:

HAPPY-PATH VERIFICATION

git rev-parse HEAD
# 9f2c1ab4e7d...  (compare with the image tag below)

gh run list --workflow=cicd.yml --limit 1
# cicd  main  push  9f2c1ab  completed  success  3m41s

kubectl get deploy app -o jsonpath='{.spec.template.spec.containers[0].image}'
# ghcr.io/tyfsadik/app:9f2c1ab4e7d...

Then prove the gates actually block bad releases, a gate you have never seen fire is a gate you cannot trust:

• Test gate: break a test on a branch, push, and confirm the run fails at the test job and no image is built or pushed.
• Scan gate: pin a vulnerable base image on a branch and confirm the scan job fails with exit code 1 and the deploy job shows as skipped.
• Branch gate: confirm that on the same PR, the deploy job is skipped because the ref is not refs/heads/main.
• Rollback path: run kubectl rollout undo deploy/app once in a test environment so you know the recovery command works before you need it.

Troubleshooting

Extension Ideas

• Add a manual approval gate for production: configure the production environment in repo Settings with required reviewers, so the deploy job pauses until a human approves.
• Deploy to AKS instead of a single cluster, using a federated workload identity instead of a stored kubeconfig.
• Add IaC apply with Terraform in the pipeline so infrastructure changes ship through the same gated workflow.
• Sign images with cosign and add a verification admission policy, extending the supply-chain gate from "scanned" to "provenance-verified".

Practice Challenges

Key Results

• Automated test, build, scan, and deploy from one commit.
• Blocked releases with critical CVEs before deploy.
• Tagged images with the commit SHA for full traceability.
• Deployed only from main, gated on green checks.