Put it in CI: the suite runs on every push

Your suite is healthy and honest; today it stops depending on you remembering to run it. CI, continuous integration, is a computer that runs your checks automatically every time anyone pushes code. Until the suite lives there, it protects exactly one machine: yours, on the days you remember. After today, it protects every change anyone makes.

GitHub Actions is the CI built into GitHub, free for public repositories, and it is configured with one small file. In your project, create .github/workflows/tests.yml:

name: tests
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Read it back, line by line, in behavioural terms. on: push means every push to the repository triggers this. The job borrows a fresh Linux machine. checkout copies your code onto it, setup-node installs Node 20, npm ci installs your exact dependencies, playwright install fetches the browsers, and then the same command you have typed all course runs the suite. The last step keeps the HTML report as a downloadable artifact, only when something failed, so a 3 a.m. red arrives with its evidence attached and your Day 14 skills apply unchanged: download the report, open the trace, scrub the filmstrip.

What a red check looks like

Push a change and open your repository’s Actions tab to watch the run live. On a pull request, the run appears as a check next to the commit: a green tick when the suite passes, a red cross when it does not, with a Details link straight to the failing test. That red cross is the suite speaking to the whole team, in public, before the change merges. Nobody has to remember to ask whether the tests were run, because the answer is pinned to the change itself.

One honest note about your suite in particular: your Day 16 boundary test is still red, so your first CI run will be red too, and that is correct. CI is now telling everyone, on every push, that the store has a money bug. On a real team that is exactly when the quarantine discipline from Day 12 matters: file the ticket, fixme with the reference, and the check stays meaningful for catching new breakage while the tracker carries the known bug.

The payoff is speed. A bug found five minutes after the push is a conversation: the developer still has the change in their head, and the fix is usually minutes. The same bug found three weeks later is an investigation, with archaeology, suspects, and a release at risk.

A suite that waits for you to remember it protects nothing. On every push, or it is a hobby.

Do this today

Put your tumble-kitchen-tests project on GitHub. This is the one day the course steps outside its own walls, so here is the short path if you have never done it:

1. Create a free account at github.com, then click New repository, name it tumble-kitchen-tests, keep it public, and create it.
2. Install GitHub Desktop (the point-and-click way to move code; the git commands can come later). Add your existing tumble-kitchen-tests folder, and publish it to the repository you just made.
3. Add the workflow file exactly as above. In GitHub Desktop, write a one-line summary and press Commit (a saved snapshot of your changes), then Push (send the snapshot up to GitHub).
4. Open your repository on github.com and watch the Actions tab run your suite on a machine you have never touched.

Two more words you will meet there: a pull request is a batch of changes offered for review before it joins the main copy, and that yml file is just a small settings file where indentation is the grammar. Tomorrow we zoom all the way out: strategy, on one page.