Axe Watcher in Continuous Integration (CI) Environments

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

How Axe Watcher detects CI pipelines and uses canonical sources for accessibility test baselines

Not for use with personal data

When Axe Watcher runs in continuous integration (CI) on your repository's default Git branch (e.g., main), that result becomes the canonical source (the single baseline that every other scan is compared against).

What Canonical Source Means

Only the default branch qualifies. Pipeline runs on feature branches or pull-request branches are recorded, but they do not become the canonical source.
The latest pipeline run wins. Each new CI run on the default branch replaces the previous baseline, so comparisons always reflect the most recent CI state.
Local runs compare against CI. When a developer runs Axe Watcher locally, their results are compared to the latest canonical source rather than to their own most recent scan. This gives every team member a shared reference point instead of individual, potentially divergent baselines.

Required Permissions

The API key used in your CI pipeline must belong to a project admin.

important

Non-admin project members cannot send data through a pipeline (the request will fail with an error).

When configuring your CI environment, ensure the API key was generated from an account with admin access to the target project in Axe Developer Hub.

Pipeline Runs on Non-Default Branches

You can run Axe Watcher in CI on any branch, but the behavior differs from default-branch runs:

Results are attributed to "Pipeline", not to the individual user whose API key was used. In Axe Developer Hub, pipeline data appears under a dedicated "Pipeline" entry rather than under a specific team member.
These runs do not become the canonical source. Only pipeline runs on the default branch set the baseline for comparisons.
Feature-branch results are still recorded. They are visible in Axe Developer Hub when the "Pipeline" view is selected, which is useful for reviewing accessibility on pull requests before merging.

CI Detection

Axe Watcher determines if it's running in CI through environment variables:

Standard CI variable: If CI is set to true, Watcher treats the run as a pipeline execution and sets the canonical source accordingly. Most CI platforms set this automatically (see Platform Support).
Explicit override: AXE_IS_CI takes precedence over CI when both are present.

Use AXE_IS_CI when the standard CI variable doesn't match your needs:
- Enable CI mode in a non-standard environment, for example, a self-hosted runner or scheduled task that doesn't set CI to true by setting AXE_IS_CI to true.
- Disable CI mode in a pipeline, for example, to run an exploratory scan in CI without overwriting the canonical source by setting AXE_IS_CI to false.

When AXE_IS_CI is set, the value of CI is ignored entirely.

Platform Support

Platform	`CI` set `true` by default	Documentation
GitHub Actions	yes	GitHub Docs - Variables Reference
GitLab CI	yes	GitLab Docs - Predefined Variables
CircleCI	yes	CircleCI Docs - Project Values and Variables
Bitbucket Pipelines	yes	Atlassian Support - Variables and Secrets
Jenkins	no (set `CI=true` or `AXE_IS_CI=true` in your `environment` block)	Using environment variables

API Key Revocation

If the API key used in your CI pipeline is deleted or the associated user account is deactivated, pipeline runs will no longer authenticate successfully. Previously recorded results remain visible in Axe Developer Hub, but no new data can be sent until the pipeline is reconfigured with a valid admin API key.

To avoid CI failures when team members leave or rotate keys, consider using a dedicated service account for pipeline API keys.