The GitHub check
Every build sets a commit status on its commit. Details on GitHub opens the build page.
States#
| Build | Check | Text |
|---|---|---|
| Shards still uploading | Pending | Waiting for screenshots (2 of 4 shards) |
| Changes to review | Pending | 12 changes to review |
| Nothing changed | Success | No visual changes |
| Every change approved | Success | 12 changes approved |
| First build of a suite | Success | Baseline created, 40 snapshots |
| Default branch | Success | Baseline updated, 12 changes |
| A change rejected | Failure | 2 changes rejected |
| Not finished in 60 minutes | Error | Build never finished |
| Upload failed on CI | Error | Upload failed, see CI logs |
| Over the storage limit | Success | Storage limit reached, not compared |
A build with changes to review stays pending until someone approves or rejects them, however long that takes. When the storage limit is reached, builds pass without being compared, so CI keeps passing. See Limits and storage.
Check name#
The check is stateofpixel. Each extra suite gets its own, like stateofpixel/storybook. See Suites.
Require it#
The CLI exits 0 when there are changes, so the CI job passes and the check decides. It blocks a merge only when GitHub requires it:
- Open the repository's settings on GitHub and add a branch protection rule or a ruleset for your default branch.
- Turn on required status checks and add
stateofpixel, plus the check of each suite that should block.
A pending check blocks the merge too, so a pull request with changes nobody reviewed cannot merge. Changes that land without review still become the baseline on the default branch. See Baselines.
Pull requests from forks get no check, because GitHub gives them no token to sign in with. See Authentication.
GitHub App permissions#
The app needs Commit statuses write to set the check, Pull requests read for the pull request number and base branch, Contents read for the compare API, and Metadata read, which every app has.