CI Basics — GitHub Actions for pytest

• Explain Continuous Integration and why CI beats "works on my machine".
• Write a GitHub Actions workflow that installs deps and runs pytest.
• Add lint + type-check + coverage steps.
• Read the CI result and use it as a merge gate.

you:    git push
GitHub: spins up a FRESH cloud machine
        → installs Python + your dependencies
        → runs ruff, mypy, pytest
        → reports ✅ pass or ❌ fail on the commit / PR

Where it lives

yourrepo/
└─ .github/
    └─ workflows/
        └─ ci.yml      ← GitHub runs this automatically on push/PR

A minimal CI workflow

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]      # run on every push and PR

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4            # get the code
      - uses: actions/setup-python@v5        # install Python
        with:
          python-version: "3.12"
      - run: pip install -e ".[dev]"         # install deps (incl. test tools)
      - run: ruff check .                    # lint
      - run: ruff format --check .           # formatting
      - run: mypy myapp                       # types
      - run: pytest --cov=myapp --cov-fail-under=80   # tests + coverage gate

Read the anatomy

on:        what triggers the run (push, PR, schedule)
jobs:      one or more jobs, each on a fresh machine
runs-on:   the OS image (ubuntu-latest, etc.)
steps:     ordered commands; if ANY step fails, the job fails (❌)

Test on multiple Python versions (matrix)

jobs:
  test:
    strategy:
      matrix:
        python-version: ["3.10", "3.11", "3.12"]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: pip install -e ".[dev]"
      - run: pytest
# → runs the whole suite on 3 Python versions in parallel

The merge gate

In GitHub branch-protection settings, require the CI check to pass before merging. Now a red CI literally blocks the merge button — the team can't ship broken code even by accident.

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
          cache: pip
      - name: Install
        run: pip install -e ".[dev]"
      - name: Lint
        run: ruff check .
      - name: Format check
        run: ruff format --check .
      - name: Type check
        run: mypy myapp
      - name: Tests + coverage
        run: pytest --cov=myapp --cov-report=term-missing --cov-fail-under=80

# on GitHub, the PR shows:
✅ CI / quality (3.11)
✅ CI / quality (3.12)
All checks have passed — merge enabled.

# or, if a test breaks:
❌ CI / quality (3.12) — pytest failed
Merging is blocked until checks pass.

Read the diff

Every push now triggers lint → format-check → types → tests-with-coverage, on two Python versions, on clean cloud machines. The PR gets a clear pass/fail; merging is blocked on red. This is the same pipeline you ran locally (Lesson 43's make check) — now enforced for the whole team, automatically, forever. CI is the capstone that ties together everything in this level.

CI runs your checks on a fresh cloud machine on every push. A GitHub Actions workflow (.github/workflows/ci.yml) checks out, installs, lints, type-checks, and tests — optionally across a version matrix. Require it as a merge gate so broken code can't reach main. CI + pre-commit + tests = the full quality system. Next: the capstone — bring a real app to 90% coverage.