GitHub PR Checks

How PR checks work

When a suite is linked to a GitHub repo, viz can run against Vercel preview deployments for pull requests.

The flow is:

1. GitHub sends a pull request webhook.
2. viz creates an in-progress GitHub Check Run.
3. Vercel sends the preview deployment webhook.
4. viz runs screenshots against the preview URL.
5. Unchanged pages pass the check.
6. Changed pages hold the check until someone approves them.
7. When the PR merges, approved screenshots become the new baselines.

Link a suite

Open the suite settings and choose the GitHub repo to link. One suite links to one repo.

If the repo is not listed, check that the GitHub App is installed on the right organisation or repository.

Make the check required

viz reports the check, but GitHub branch protection decides whether it blocks merging.

In GitHub, add the configured check name as a required status check for the protected branch. The default name is viz / visual-regression.

Approving PR changes

Approving visual changes in a PR run does not update baselines straight away. It marks the changes as accepted and unblocks the GitHub check.

Baselines are promoted only when the PR is merged. This keeps main baselines tied to code that actually landed.

Troubleshooting

• If a PR has no check, confirm the suite is linked to the same owner and repo.
• If a check stays in progress, confirm Vercel is sending preview deployment webhooks.
• If the check is successful but merging is not blocked, confirm branch protection requires the exact check name.