Lesson 04 — GitHub Actions Pipeline

Build, test, and lint the URL shortener on every push.

Cloud & DevOps Module 2

Why CI exists

• Catches regressions before merge — every PR gets a “green check” contract before a reviewer sees it
• Gives confidence to move fast — automated tests mean a bad push is caught in minutes, not at 2 AM in production
• Produces the artifact L06 deploys — the CI pipeline is the factory that builds your image from a known commit
• Eliminates “works on my machine” — the runner is a clean environment every time; no lingering local state

Without CI, the team becomes the test suite — manually verifying changes before every merge.

The shape of a GitHub Actions workflow

  workflow (ci.yml)
  ├── job: lint
  │   ├── step: checkout
  │   ├── step: setup-python
  │   └── step: ruff check
  ├── job: test
  │   ├── step: checkout
  │   ├── step: pytest
  └── job: build
      ├── step: checkout
      └── step: docker build
      

Triggers — on:

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

• push triggers on direct commits to main (e.g., after merging a PR)
• pull_request runs on every commit pushed to a PR targeting main
• Other common triggers: schedule (cron), workflow_dispatch (manual button), workflow_call (reusable workflows)

Runners

• ubuntu-latest — default; free for public repos, included minutes for private; best price/performance
• macos-latest — needed for iOS/macOS builds; 10× cost of Linux
• windows-latest — needed for .NET/Windows testing; 2× cost of Linux

Self-hosted runners exist for special needs: GPU workloads, access to private networks, compliance requirements. The runner agent connects outbound to GitHub — no inbound ports required.

Job basics

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

• Every job starts with actions/checkout — clones the repo onto the fresh runner
• A language setup step (setup-python, setup-node, etc.) configures the toolchain
• Then your commands run exactly as they would locally
• Jobs can declare needs: to form a DAG — build only after lint + test pass

Matrix builds

strategy:
  matrix:
    python-version: ["3.10", "3.11", "3.12"]
steps:
  - uses: actions/setup-python@v5
    with: { python-version: "${{ matrix.python-version }}" }

• One job spec, N parallel runs — each with a different value from the matrix
• Use when you officially support multiple Python/Node/Go versions
• Add include: to add specific extra combos; exclude: to subtract

Caching dependencies

- uses: actions/setup-python@v5
  with:
    python-version: "3.11"
    cache: pip
    cache-dependency-path: api/requirements.txt

The cache: pip shortcut on setup-python stores the pip download cache keyed on the hash of your requirements file. On subsequent runs with the same requirements, installation is skipped entirely.

• Saves typically 30–90 seconds per job once the cache warms
• Cache is scoped per OS + Python version automatically
• Falls back to full install if the requirements file changes

Linting in CI

• ruff check api worker — style and bug detection (replaces flake8/pylint)
• ruff format --check api worker — formatting check; fails if files are not auto-formatted (replaces black --check)
• Same ruff config that runs in the developer’s editor — no surprises at CI time

- name: Install ruff
  run: pip install ruff==0.6.9
- name: Lint
  run: ruff check cloud-devops/sample-app/api cloud-devops/sample-app/worker
- name: Format check
  run: ruff format --check cloud-devops/sample-app/api cloud-devops/sample-app/worker

Pinning ruff==0.6.9 prevents a new ruff release from suddenly failing your build.

Building the Docker image in CI

- uses: docker/setup-buildx-action@v3
- uses: docker/build-push-action@v5
  with:
    context: ./api
    push: false
    tags: api:ci
    cache-from: type=gha
    cache-to: type=gha,mode=max

• docker/setup-buildx-action enables BuildKit features (multi-stage, layer cache export)
• push: false builds without pushing — validation only; L06 adds the push
• type=gha uses GitHub’s per-repo cache backend — layers survive across runs
• Can shave several minutes on complex multi-stage builds after the cache warms

Status checks and the “green check” workflow

• Each job reports its status back to the commit SHA on GitHub
• A green check on a PR means all required jobs passed
• Branch protection (covered in L05) can require specific checks before merge
• Without branch protection, the check is informational — useful but not enforced

What we’ll build in lab

The ci.yml pipeline for the URL-shortener sample app:

• Job 1: lint — ruff check + ruff format --check on api + worker; pip cache keyed on requirements files
• Job 2: test — pytest on api/tests + worker/tests; Python 3.11/3.12 matrix; pip cache; fail-fast: false
• Job 3: build — Docker buildx for api and worker; GHA layer cache per service; depends on lint + test

Common gotchas

• Unpinned action versions — actions/checkout@main silently changes behavior when GitHub updates the action. Pin to a major version (@v4) at minimum; pin to a SHA for supply-chain paranoia.
• Matrix explosion — 3 Python versions × 3 OS = 9 runners; with macOS at 10× cost you can burn serious minutes. Start small and add dimensions only when you need them.
• Re-running on doc edits — a README typo fires the full pipeline unless you add paths-ignore: ['**.md']. Path filters are cheap to add and free to run.
• Missing fetch-depth: 0 — the default shallow clone breaks tools that need full git history (changelog generators, git-based versioning).

Recap & what’s next

• A workflow is one YAML file in .github/workflows/ — triggers, jobs, steps
• Matrix + cache are the two biggest CI accelerators: matrix parallelizes; cache eliminates redundant work
• The green check is the PR contract — code passed lint, test, and build on a clean runner