Week 6: CI/CD with GitHub Actions

1. Workflow, Job & Step Anatomy

A GitHub Actions workflow is a YAML file in .github/workflows/ that describes what should run and when. Each workflow contains one or more jobs, and each job runs a sequence of steps on its own fresh virtual machine. Jobs run in parallel by default; steps within a job run in order, on the same machine, sharing its filesystem.

name: CI

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

A step is either uses:, which runs a reusable, published action (a packaged unit of automation — actions/checkout clones your repo onto the runner, since a fresh VM starts with no code on it at all), or run:, which executes a shell command directly. Steps share files and environment variables within a job but nothing carries over between separate jobs unless you explicitly pass it with outputs or an uploaded artifact.

2. Triggers & Runners

The on: block decides what causes a workflow to fire. The two you'll use constantly are push (code landed on a branch) and pull_request (a PR was opened or updated) — and it's common to run a different subset of jobs for each, since a PR needs feedback before merge but only main should ever trigger a deploy.

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  workflow_dispatch:      # adds a manual "Run workflow" button in the UI

runs-on: chooses where a job's steps actually execute. GitHub-hosted runners (ubuntu-latest, windows-latest, macos-latest) are fresh VMs GitHub provisions, runs your job on, and destroys — zero maintenance, generous free minutes on public repos, but capped CPU and no access to anything inside your private network. A self-hosted runner is a machine you register yourself (on-prem, in your own VPC, or even a beefy build server) — necessary when a job needs GPU hardware, a private network resource, or simply costs less to run continuously than paying per-minute for hosted compute.

# From: repo Settings > Actions > Runners > New self-hosted runner
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.319.1.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.319.1/actions-runner-linux-x64-2.319.1.tar.gz
tar xzf actions-runner-linux-x64-2.319.1.tar.gz
./config.sh --url https://github.com/<org>/<repo> --token <REGISTRATION_TOKEN>
./run.sh

Then reference it with a label instead of ubuntu-latest: runs-on: self-hosted.

3. Encrypted Secrets

A registry token or cloud credential should never appear as literal text in a workflow file — anyone who can read the repository can read the file. GitHub Actions secrets solve this: values stored encrypted at rest, readable only inside a running workflow through the secrets context, and automatically redacted (replaced with ***) if a step accidentally prints one to the log.

# Repo > Settings > Secrets and variables > Actions > New repository secret
# Name: DOCKERHUB_TOKEN   Value: <paste the token>

# Or via the GitHub CLI
gh secret set DOCKERHUB_TOKEN --body "dckr_pat_xxxxxxxxxxxxx"

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ vars.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

Secrets aren't passed to workflows triggered from a fork's pull request by default — a deliberate protection, since anyone could otherwise open a PR from a fork with a workflow that exfiltrates your secrets to an external URL. Non-sensitive configuration (a bucket name, an AWS region) belongs in variables (vars.) instead of secrets — it keeps the Actions log readable and avoids "why is this masked" confusion for values that were never sensitive.

4. A Build-Test-Push Pipeline

Putting it together: a single workflow that runs your test suite, then — only if tests pass and the change landed on main — builds the Docker image, logs in with a secret, and pushes it tagged with the commit SHA, exactly as you did by hand in Week 5.

name: Build, Test & Push

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"
      - run: npm ci
      - run: npm test

  build-and-push:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ vars.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build image
        run: docker build -t ${{ vars.DOCKERHUB_USERNAME }}/orders-api:${{ github.sha }} .

      - name: Scan image
        run: |
          docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
            aquasec/trivy image --severity HIGH,CRITICAL --exit-code 1 \
            ${{ vars.DOCKERHUB_USERNAME }}/orders-api:${{ github.sha }}

      - name: Push image
        run: docker push ${{ vars.DOCKERHUB_USERNAME }}/orders-api:${{ github.sha }}

needs: test makes build-and-push wait for the test job and skip entirely if it fails — a broken build never reaches the registry. The if: condition restricts the push itself to direct pushes on main, so opening a pull request still runs the full test suite for feedback without ever pushing an image. github.sha gives you the exact same immutable, git-SHA-based tagging scheme from Week 5, generated automatically instead of typed by hand.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.