CI/CD with GitHub Actions

Work inside churn-repo with the 4.5 suite green locally (pytest -q prints 14 passed) and the repo pushed to GitHub as origin, the 0.2 way. Everything below runs on GitHub's free tier.

Step 1 — the workflow file, line by line. One new file, in a folder GitHub watches:

# .github/workflows/ci.yml — the referee's instructions
name: ci

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install pinned packages
        run: pip install -r requirements.txt
      - name: Train the model (models/ is gitignored)
        run: python train.py
      - name: Run the 4.5 suite, gate included
        run: pytest -q

Read it top to bottom. name: ci labels the workflow — this exact string returns in the badge and in branch protection. on: lists two triggers: every push and every pull request. One job called test runs on ubuntu-latest, a fresh Linux runner. The two uses: lines borrow marketplace actions: checkout clones the repo onto the runner, setup-python installs 3.12 on a machine that woke up with nothing. Then three run: lines replay 4.1's clone ritual. The train step is the line most teams forget: models/ is gitignored by 4.1's decision, so the runner has no joblib — yet the 4.5 gate and smoke tests load it. Delete that line and the run dies with FileNotFoundError, which is WR-106 in one sentence.

Step 2 — push it and watch the first run. Commit, push, then open your repo's Actions tab in the browser:

$ git add .github/workflows/ci.yml
$ git commit -m "Add CI: install, train, test on every push"
$ git push

# GitHub -> Actions tab -> run "Add CI: install, train, test..." -> job: test
✓ Set up job                            2s
✓ Run actions/checkout@v4               1s
✓ Run actions/setup-python@v5           4s
✓ Install pinned packages              46s
✓ Train the model (models/ is gitignored)  9s
✓ Run the 4.5 suite, gate included     11s
    ..............                   [100%]
    14 passed in 4.18s
✓ Complete job                          1s

Each line is one step from the YAML, with its wall-clock cost — the pip install dominates at 46 seconds, a number step 4 will attack. Click any step to unfold its full log. The last step's log is your 4.5 board, unchanged: 14 passed, the same fourteen promises, now verified on a machine you have never touched. Back on the repo's main page, the commit now carries a green tick — the referee's signature. Total run: about 1 minute 14 seconds.

Step 3 — break it on purpose, then read the failure down to the assert. Real failures arrive on branches, so stage this one properly. Branch off (git checkout -b break-ci), plant 4.5's divisor bug in src/features.py (/ 3 becomes / 30), commit, push, and open a pull request. The PR page grows a red X within two minutes. Click Details:

✗ Run the 4.5 suite, gate included
    F.............                   [100%]
    =================== FAILURES ===================
    _______ test_known_customer_worked_by_hand _______
    >       assert out.loc[0, "spend_share"] == pytest.approx(0.025)
    E       assert 0.0025 == 0.025 ± 2.5e-08
    tests/test_features.py:21: AssertionError
    1 failed, 13 passed in 4.21s
    Error: Process completed with exit code 1.

Read it in the 4.5 order: the scoreboard (F.............), the failing test's name, the > arrow on the stopping line, the E line holding both numbers, then file and line. The only new line is the last one — exit code 1 is pytest telling the runner it failed, and any non-zero exit turns the step, the job and the whole run red. Now give that red X teeth. In the repo: Settings → Branches → Add branch protection rule for main, tick "Require a pull request before merging" and "Require status checks to pass", and select the test check. On the free plan this is enforced on public repos — and churn-repo is safe to make public, because 4.1's gitignore kept the data, the model and every key out of history. Reload the PR: the merge button now reads "Merging is blocked". Fix the divisor, push, watch the X turn into a tick, and merge — the full green-before-merge loop you will drill in exercise 2.

Step 4 — cache pip, measure the speed-up. The 46-second install re-downloads the same wheels on every run. Tell setup-python to keep them:

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: "pip"        # cache key = a hash of requirements.txt

Push once to fill the cache (this run still pays full price and ends with "Cache saved"). Push again and compare: the install step opens with Cache restored from key: setup-python-...-requirements.txt, the install drops from 46 s to 6 s, and the whole run from 1 m 14 s to about 34 s. The comment explains the rule: the cache key is a hash of requirements.txt, so code edits reuse the cache forever, while changing a pin rebuilds it exactly once. Two more hygiene habits while you are here. A failed step skips everything after it, so keep cheap steps before expensive ones — red should arrive early. And when a library must support several Python versions, one matrix: block runs the same job on each version in parallel; you do not need it today, but name it in interviews.

Step 5 — a secret in CI, done right. In the repo: Settings → Secrets and variables → Actions → New repository secret. Name it PROVIDER_API_KEY, paste a practice value (a real one arrives with 4.7). Then let a step prove the key arrives without ever showing it:

      - name: Prove the key arrives - never print it
        env:
          PROVIDER_API_KEY: ${{ secrets.PROVIDER_API_KEY }}
        run: python -c "import os; print('key length:', len(os.environ['PROVIDER_API_KEY']))"

The env: line is the only bridge: GitHub decrypts the secret and hands it to this one step as an environment variable — the same door your .env file used in 3.2, in a new home. The log prints key length: 21 and nothing else. If a step does echo the value, Actions masks it to *** in the log — but treat masking as a seatbelt, not a licence: print the string reversed or encoded and the mask misses it completely. So the rule stays behavioural: secrets live in repository secrets, never in YAML, and never in a print. If a real key ever lands in a log, it is public — rotate first, in WR-006's order. That is WR-107's whole story.

Step 6 — the referee builds the 4.3 box, and the deploy gate waits. Each job gets its own fresh runner, so the joblib the test job trained died with its machine. An artifact — a file a job uploads so later jobs, or a human, can download it — is how the model travels. Append an upload to the test job, then add two jobs:

# appended to the test job — hand the trained model forward:
      - uses: actions/upload-artifact@v4
        with:
          name: churn-model
          path: models/churn_pipeline.joblib

# two new jobs, below test:
  docker:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: churn-model
          path: models/
      - run: docker build -t churn-service .
      - name: Smoke the box
        run: |
          docker run -d -p 8000:8000 churn-service
          sleep 5
          curl --fail http://localhost:8000/health

  deploy:
    needs: docker
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest
    steps:
      - run: echo "Green across the board. The real deploy lands in 4.7."

needs: draws the pipeline: test, then docker, then deploy — a red test job cancels everything after it. The docker job downloads the artifact into models/, exactly where 4.3's Dockerfile COPY expects the file, then builds churn-service and curls /health inside the runner: {"status":"ok","model_loaded":true}. If your locked-down laptop never got Docker rights, this is your catch-up — the runner ships with Docker preinstalled and full rights, and it builds the 458 MB box your machine could not. The deploy job is the honest CD story: it waits for docker, runs only on main, and its environment: production can be configured (Settings → Environments) to pause until a named human clicks approve. Today its one step prints a sentence; in 4.7 the same slot deploys to AWS. The gate is finished before the destination exists — that is deliberate.