Ctrlk
x-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Core concepts

The core concepts behind Argos — builds, baselines, comparisons, and the statuses you see on your pull requests.

Argos turns the screenshots your tests produce into a review signal on your pull requests. This page defines the concepts you'll meet everywhere else in the docs.

Builds and snapshots

A build is the result of one test run: the set of screenshots (and other snapshots, like ARIA snapshots or text files) uploaded together from your CI. Each build belongs to a project and is tied to a commit and branch.

A build goes through three stages:

  1. Upload: Your CI uploads the snapshots, either automatically through an SDK or with the CLI.

  2. Comparison: Argos picks a baseline build and diffs each snapshot against its counterpart.

  3. Conclusion: The build concludes with No changes detected or Changes detected, and Argos reports it to your Git provider as a commit status.

Build types

Argos assigns each build a type that describes how it is compared:

  • Check: The standard build on a feature branch — compared against a baseline and awaiting review when changes are detected.

  • Auto-approved: A build on an auto-approved branch (your default branch by default) — approved automatically so it can serve as a future baseline.

  • Orphan: A build with no baseline to compare against — expected for a project's first builds.

  • Skipped: A build intentionally marked as skipped — reports success without screenshots.

Review

When a build concludes with Changes detected, your team reviews it: approve the changes to accept them as the new expected state, or reject them to flag a regression. The review outcome updates the commit status on your pull request, so you can require it before merging.

Go deeper

Once the concepts are clear, head to the Review workflow to see how builds are reviewed day to day.

Last updated

Was this helpful?