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

Build modes

Compare Argos Continuous Integration mode and Monitoring mode to choose the right one for your workflow.

Argos provides two build modes: Continuous Integration (CI) mode and Monitoring mode. They differ in one thing — how the baseline is chosen. CI mode follows your Git history to review changes branch by branch; Monitoring mode ignores Git history and tracks drift against the latest approved state.

CI mode

CI mode is the default. It is designed to review the visual changes introduced by a feature branch and prevent regressions from merging.

On each pull request and on your default branch, your tests capture screenshots and upload them to Argos. Argos compares them against the baseline build selected from your Git history, and reports the result on the pull request.

Your CI pipeline must also run on the default branch (main, production, etc.) to keep the baseline up to date.

Workflow

1

Develop

A developer creates a feature (or bugfix) branch, commits changes, and opens a pull request.

2

Capture and upload

During CI, your test framework captures screenshots of the app. At the end of the tests, the Argos SDK uploads them automatically — or you upload them with the CLI.

3

Compare

Argos determines the baseline build from your Git history and compares each new screenshot against it.

4

Report

Once all screenshots are compared, the build concludes:

  • No changes detected — the commit status passes.

  • Changes detected — the commit status asks for review, and the diffs are ready in Argos.

Argos posts the status to your Git provider, along with a pull request comment on GitHub. If your branch protection requires the Argos check, the pull request is blocked until the changes are reviewed.

5

Review

The team reviews the build: approve intended changes or reject regressions. The commit status updates accordingly, and approved builds become eligible as future baselines.

When to use CI mode

  • Pull request validation: Block merging until visual changes are reviewed and approved.

  • Default branch verification: Validate every merge so the baseline stays trustworthy.

  • Continuous feedback: Surface regressions commit by commit, where developers work.

CI mode is enabled by default — follow the Quickstart to set it up.

Monitoring mode

Monitoring mode is opt-in. It is designed to track visual changes outside the standard CI flow — on a schedule, before a release, or after a deployment.

In this mode, your tests capture screenshots on a chosen branch (e.g., main or a release branch). Argos compares them only against the latest approved build: Git history is ignored, and the approval status alone defines the baseline.

Workflow

1

Run on a schedule

Your tests capture screenshots on the target branch — daily, weekly, or before a release.

2

Compare with the latest approved build

Argos compares the screenshots against the most recently approved monitoring build.

3

Get notified and review

If differences are found, Argos notifies you — enable Slack notifications to alert your team immediately. Review the changes, then approve them or fix the regression.

When to use Monitoring mode

  • Regular health checks: Catch unexpected changes on a schedule when running CI on every change isn't practical.

  • Pre-release validation: Confirm no regressions slipped in before a major release.

  • Post-deployment monitoring: Detect environment-specific issues after staging or production deployments.

  • Third-party integrations: Ensure external widgets or services that change independently remain visually stable.

Enable Monitoring mode

Set the mode in your SDK configuration or pass --mode=monitoring to the CLI:

Builds in different modes never share baselines: a monitoring build is only ever compared against another monitoring build.

Last updated

Was this helpful?