Rules and tests say what to check. The Verify tab shows what came of it: which builds passed, where differences were found, and which of them a human has already worked through. This is the main screen of the visual layer — the counters on the product’s home page lead here.
The Build List
The tab opens with the build list — newest first. At the top there are three filters: branch, mode, and review state. A build’s row immediately shows how many snapshots changed, how many are new, and how many were captured in total.
If the project has only just been set up and there are no builds yet, the tab offers to run the first one — with the “Run your first build” button.
Build Modes
The mode decides how many checks to run. There are three:
- Full build — runs every declared check. The most honest and the slowest mode; it makes sense before a release or on a nightly schedule.
- Smart build — runs only the affected checks. Suited for everyday work: less time, less noise.
- Comparative build — compares two environments against each other, for example test and production. Useful when you need to confirm that the production site looks exactly like the test one.
Review States
A build has one of five states:
- “Snapshots await review” — nobody has looked at the differences yet.
- “Changes requested” — a reviewer looked and sent it back for rework.
- “Approved” — the differences are accepted, the baselines updated.
- “Rejected” — the changes are declared unnecessary or wrong.
- “Merged” — the build is merged into the main branch.
Next to the state there is always a reason — why it is exactly this one. For example: “Snapshots await review”, “All snapshots approved earlier”, “Auto-approved by a branch rule”, “Rejected by a reviewer”, “No visual changes”, “Some snapshots failed to compare”, “Some snapshots did not arrive”. This way you see not only what was decided, but on what grounds.
The Build Page
Inside a build there are steps with labels and snapshot rows. Each row has its own status:
- pending — the snapshot is still being taken;
- unchanged — matched the baseline;
- changed — there is a difference that needs looking at;
- new — there was no baseline yet, one was created automatically;
- removed — the place that used to be captured no longer exists;
- missing — the snapshot never arrived (for example, the connection to the runner dropped);
- skipped — the step did not run in this mode.
While the build runs, the page updates itself: you see “Running”, which step of how many, and which browser the runner is holding. The runner’s name is on the page — so it is clear on which machine everything happened.
What you can do with a build:
- Retry failed — rerun only the steps that did not pass.
- Queue a new build — run this same test again.
- Mark as failed — with a mandatory reason: “Flaky run — passes on retry”, “Environment problem — not a product change”, “Infrastructure failure during the run”, “Known regression — tracked separately”. This is needed so that a failed run is not passed off as a finding.
- Delete build — together with its steps, checks, and snapshots. The baselines are not touched.
The Verdict and Bulk Acceptance
At the top is the verdict line: “Visual: pass”, “Visual: review required”, “Visual: fail”, or “Visual: no data”. Next to it is a counter of how many decisions are not saved yet.
Through that counter, the “Accept all safe” button opens. Only differences whose safety was proven by strict rules are accepted in bulk: for example, a shift of a few pixels inside a region closed by a mask. Everything disputable stays for row-by-row review — a bulk action cannot smuggle an unnoticed regression through. How many differences are safe and how many are left for the human is shown right in the confirmation dialog.
Evidence
After a build, every step keeps a snapshot and its check results. So when something breaks, you see not only that it fell over, but at which exact step and what the page looked like at that moment. The same evidence is attached to the fix todo and lands in the report.
Next: how to look at a difference itself and decide its fate — in Diff Viewing.