GitHub pull request status checks
Connect Snapvisor to GitHub for build status checks on your pull requests, including a light install that works without read access to your code.
Install the Snapvisor GitHub App and every build posts a status check back to the pull request — so nothing merges with an unreviewed visual change.
What the app does
The GitHub App links your repositories so Snapvisor can post commit and pull-request status checks. It reads the PR's base branch to resolve the baseline and reports whether each build has unreviewed changes.
Check names and states
Snapvisor posts its check under the name snapvisor. When several projects share a repository the name carries the project (snapvisor/<project>), a named build adds its name (snapvisor/<build>), and the summary check is snapvisor/summary. GitLab shows the same names on commit statuses.
| Build state | Check state | Description |
|---|---|---|
| Queued or processing | Pending | "Build is queued" or "Build in progress..." |
| Changes waiting for a reviewer | Pending | "N changes awaiting review" (or "1 change awaiting review") |
| Approved, auto-approved, or no changes | Success | The approval or "no changes found" |
| Rejected by a reviewer | Failure | The stats and "rejected" |
| Expired, screenshots never arrived | Failure | "Build expired — screenshots never arrived" |
A build with unreviewed changes is pending, not failed: nothing is broken, a person just has not decided yet. The check only fails when a reviewer rejects the changes.
Until recently the check was named argos (and argos/summary), and unreviewed changes showed as failed. To give you time to switch, Snapvisor keeps posting the old names, with the same state as the new ones and a description that starts with "deprecated:", until 2026-11-25. After that date only the snapvisor names are posted, and a rule that still asks for the old name waits for a check that is never posted and blocks the merge.
Before 2026-11-25, in your repository's branch protection or ruleset, replace the required check argos with snapvisor and argos/summary with snapvisor/summary (a named build or a project in a shared repository follows the same pattern: argos/<name> becomes snapvisor/<name>).
Only required checks block a merge. A pending snapvisor check holds a pull request until someone approves or rejects the changes; a check that is not required never does.
GitHub integration without content permission
If your security policy won't grant a third party read access to your source, install the light GitHub App variant instead. It requests no content permission — Snapvisor never reads your code — and still posts status checks on your pull requests.
The light install is a separate GitHub App connection on your team. You can switch to it, or uninstall it, at any time from your team's settings.
Reviewing screenshots on the pull request
For the whole loop — upload, status check, comment, review and approve — see visual regression testing in GitHub pull requests. To run it in a workflow, use GitHub Actions.
Authentication in CI
On GitHub Actions you don't have to store an ARGOS_TOKEN at all. Snapvisor supports tokenless authentication and short-lived OIDC tokens so builds authenticate without a long-lived secret. For workflows covering merge queues, shallow checkouts, fork pull requests and re-runs, see GitHub Actions recipes.
Review workflow
How Snapvisor baselines, approvals, monitoring mode, flaky-change detection, and summary checks work together.
GitLab merge request statuses
Connect Snapvisor to GitLab with a personal access token so build results appear as commit statuses on your merge requests, including self-managed GitLab.