Lesson 6 of 6
Make CI run the checks — and do not deploy from this module
Add a GitHub Actions verify job that installs from the lockfile, runs types, tests, Playwright, and build, blocks on red, and leaves deploy commented out with a written rollback plan.
CI answers “keep this commit?” — not “ship to users?”
A check you only run locally is a habit, and habits lapse. CI runs the same commands on a machine that is not yours. That answers is this change good enough to keep? Deployment answers should users get it? This module does the first column only.
A green verify job means: on that commit, in that runner image, install, typecheck, unit/integration tests, browser tests, and production build succeeded. It does not mean the app is correct for every user, accessible in the WCAG sense, or live on a URL. Write that sentence in your notes. Do not let “green” stand in for deploy.
The example workflow ends with a commented deploy job (needs: verify, environment: production). Leave it commented. You are not asked to ship from this lesson.
Write a verify workflow that actually runs browsers
The starter includes the complete .github/workflows/ci.yml — copy that file, rather than reconstructing YAML from a list of steps. It has push, pull_request, and manual triggers; permissions: contents: read; a 15-minute verify job; and current Node 22. Its action majors are deliberately pinned. Check official action release notes before updating them.
After npm install, commit package-lock.json: npm ci in CI needs it. The workflow runs checkout → Node setup → npm ci → typecheck → unit/integration tests → npx playwright install --with-deps chromium → browser tests → production build. It uploads playwright-report/ on failure. The deploy sketch at the end remains commented out.
Run all the same commands locally once before opening a pull request. Then inspect the actual Actions logs: a workflow file on disk does not prove the runner executed it, and zero tests is not a passing test suite.
Required checks, a sketched approval gate, no GitHub agent bot
Push a branch and open a pull request. Confirm the verify job runs. Then break an assertion on purpose, push, and confirm the job is red. Restore it. Save both run URLs.
If the repository allows it, add a branch protection rule (or ruleset) so verify is a required status check. Protected branches and required checks are documented by GitHub; private repos on some plans cannot use every protection. If you cannot enable the rule, write that limitation instead of claiming it is on.
A GitHub environment with required reviewers is the shape of a later deploy job: the job waits until a person approves. Sketch that in comments; do not turn it on as an active deploy. Do not run opencode github install in this module. That bot can review or edit pull requests; here the checks are tests and the reviewer is you.
Write a rollback runbook with a real revision
A rollback plan is real only with a hash, a command, and a verification step you would actually run:
# Rollback — task tracker
- Last known-good revision: <full sha>
- This module does not deploy. To undo a bad commit: git revert <sha>; push; wait for verify
- In-session agent edits: OpenCode /undo or git restore (not production)
- Data: not applicable — browser localStorage only; do not “roll back” a visitor’s device
- Who approves a future deploy: <you>
Fill the sha with git rev-parse HEAD after a green verify. Do not leave placeholders. Then write one honest status line: “verify green on <sha> means types, tests, e2e and build passed; it does not mean deployed or certified.”