CI setup
How the reporter recognises your CI, what it reads from it, and why CI runs and local runs are counted apart.
How the reporter recognises CI
Section titled “How the reporter recognises CI”The reporter looks for each supported provider’s own variables: GitHub Actions,
GitLab CI, CircleCI, Jenkins, Azure Pipelines, Bitbucket Pipelines, Buildkite,
TeamCity, AWS CodeBuild, Travis CI and Drone. A recognised provider always
counts as CI, even when CI=false is set.
On any other CI system the generic CI variable decides - but only the values
true or 1 (in any case). CI=false, CI=0 or no CI at all makes the
run a local run. An empty variable counts as unset.
Why it matters
Section titled “Why it matters”Squally tells CI runs and local runs apart. Every page with figures - the dashboard, the tests and the errors - shows both by default; its All · CI · Local switch shows CI runs or local runs on their own. Under CI, a local run never changes a test’s stability, flaky rate or failure rate. Local runs are listed with all other runs in the runs list.
What the reporter reads
Section titled “What the reporter reads”| Where it comes from | |
|---|---|
| Run ID | the provider’s build or workflow ID - shared by all shards of one CI run, so they become one run in Squally - with the job key added when one is set. SQUALLY_CI_RUN_ID overrides it. See Sharded runs. |
| Job key | SQUALLY_CI_JOB_KEY, which you set per job when one CI run has several jobs that are not shards of each other - a browser matrix, an api and a ui suite. Each job is then a run of its own (squally-reporter 0.11.0). See Jobs that are not shards. |
| Link to the CI run | the CI run’s page, on GitHub Actions, GitLab CI, Jenkins, Buildkite, Travis CI and Drone (squally-reporter 0.11.0) - the run page’s View in CI. See The link to the CI run. |
| Branch | the provider’s branch variable; for a pull request, its source branch. A tag build has no branch. Where the provider has none, the branch git reports. |
| Commit | the provider’s commit variable; for a pull request, its head commit. Otherwise git rev-parse HEAD. |
| Commit message and author | git, for the reported commit; CI_COMMIT_MESSAGE and CI_COMMIT_AUTHOR (GitLab CI) are used when set. On GitHub Actions, GITHUB_ACTOR - who started the workflow - only when git cannot read the checkout. |
| Event | GitHub Actions and GitLab CI only: the event that started the run, such as push or pull_request. |
The reporter sends no pull-request number. Squally’s GitHub integration finds the pull request by its head commit.
Each provider in detail: GitHub Actions, GitLab CI, Azure Pipelines, other providers. Which revision of your application a run tested is a separate, opt-in setting: Tested revision.
What you set
Section titled “What you set”One variable, on every provider:
SQUALLY_INGEST_KEY=your-project-ingest-keyThe reporter sends to https://app.squally.dev unless SQUALLY_INGEST_URL
names another Squally. Without the key it warns and sends nothing. See
Keys.
How the key reaches the test step differs: GitHub Actions and Azure Pipelines
need it mapped in env:, GitLab CI and most other CIs hand a secret variable
to every job. In the app, each project’s Run it in CI page has the steps
for GitHub Actions, GitLab CI, Azure Pipelines and other CIs - see
The setup page.