The build pipeline needs to understand on its own whether it may move on, without peeking into the product’s interface. For that there is the computed check status, a command-line tool, and notifications about what needs a human decision.
There is one main rule here: the check gives evidence, and the decision stays with the human. No flag, key or script changes that.
The check status
The status is not stored ready-made — it is recomputed from live data on every read:
- Pending — changed captures await a human decision.
- Failure — there are failed builds, rejected captures, or errored comparisons.
- Success — only after the differences have been approved.
One honest detail: a build that selected no checks is a failure, not an automatic pass. An empty check list never counts as success.
The check text
The status always travels with a check text: what exactly the build selected, plus any override with the author’s name and the reason. The pipeline response, the pull request comment, and the machine address return the same thing — there is never a divergence between them, because all three compute from the same data.
The pull request comment
Before a merge, the pipeline leaves a comment listing every capture awaiting a decision. A person does not have to hunt for them across the interface: the build opens from the link in the comment, and the verdicts are delivered there.
The command line (viz)
The same things are available from the command line: run a build and wait for the verdict, view the state, get the “what awaits a decision” list, request changes or a heal, export and import baselines, publish a link, read the check status, view the settings, and upload a capture from another tool. The tool needs no install and no build — it is a plain runnable file.
The exit codes are the contract with the pipeline:
- 0 — passed.
- 7 — passed, but a human decision is required.
- 8 — failed.
The machine-output flag gives the same facts as data instead of text — handy for parsing in scripts. And the most important part: an “approve” command does not exist. The tool may request changes, open a todo, and show what a human could accept with one click — but the acceptance itself happens only in the browser and only by human hands. This is not a restriction that another key could lift.
Override
Sometimes a red check must be bypassed consciously — when the difference is known and the release will not wait. A reason is named, and it is mandatory. The computed verdicts stay untouched: the check text gains a “bypassed by user …” line with the reason, so a bypass is always visible. Only a finished build can be bypassed, and only an administrator can do it.
Notifications
Notifications go to a set URL on events. Two are on by default: “review required” and “build failed”. Two more are available — “share published” and “escalation opened”. The “review required” event has a difference-count threshold: a one-pixel difference will not wake anyone.
Failed deliveries are retried, and the delivery log shows what was sent and what failed. When the product’s public address is not set, the links in a notification honestly stay relative — they can only be opened from the same server. When the address does not answer, notifications pause, but the testing itself keeps working.
Next: who executes the builds and what the operations section shows — in Operations & Health.