GitLab CI

The pipeline

playwright:
  # Use the image tag that matches your @playwright/test version.
  image: mcr.microsoft.com/playwright:v1.62.1-noble
  parallel: 3
  script:
    - npm ci
    - npx playwright test --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL

Add SQUALLY_INGEST_KEY as a CI/CD variable in your GitLab project (Settings → CI/CD → Variables → Add variable): masked, not protected. GitLab may tick Protect variable for you, and a protected variable reaches only pipelines on protected branches and tags - a pipeline on any other branch runs the tests and sends nothing. SQUALLY_INGEST_URL is not needed: the reporter sends to https://app.squally.dev by default. In playwright.config.ts, replace the reporter line and check that retries are on in CI - Playwright’s template already has that line:

import { defineConfig } from "@playwright/test";

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  reporter: [["html"], ["squally-reporter"]],
});

Replace, don’t add: with a second reporter: key the later one wins without a warning. Keep any other reporters in the list.

Checks and merge request comments are GitHub only today: a GitLab project gets no commit status and no merge request note from Squally. See GitHub. When a project’s recent runs all come from GitLab and it links no GitHub repository, the GitHub card on its Integrations tab says so in grey: “Runs come from gitlab.com - GitHub checks do not apply”.

Shards

The jobs of a parallel: group share CI_PIPELINE_ID, and the reporter uses it as the run ID: the shards become one run in Squally. See Sharded runs.

Every other job of the pipeline shares CI_PIPELINE_ID too. Two Playwright jobs that are not shards of each other - an api and a ui job, or a parallel: matrix: over browsers - need a job key each (squally-reporter 0.11.0): set SQUALLY_CI_JOB_KEY per job, for example SQUALLY_CI_JOB_KEY: ui in the job’s variables:. The run ID becomes <CI_PIPELINE_ID>-<key>, and each job is a run of its own. See Sharded runs.

The link to the pipeline

Since squally-reporter 0.11.0, the run’s page in Squally links to the pipeline as View in CI, from CI_PIPELINE_URL - the pipeline’s page, not one job’s.

Branch, commit and merge requests

Pipeline	Branch	Commit
Branch	CI_COMMIT_BRANCH	CI_COMMIT_SHA
Merge request	CI_MERGE_REQUEST_SOURCE_BRANCH_NAME	CI_MERGE_REQUEST_SOURCE_BRANCH_SHA in merged-results pipelines, otherwise CI_COMMIT_SHA
Tag	none	CI_COMMIT_SHA

The commit message and author come from CI_COMMIT_MESSAGE and CI_COMMIT_AUTHOR; in a merged-results pipeline, from the source branch’s head commit instead (fetched if a shallow clone lacks it). The event comes from CI_PIPELINE_SOURCE. Where a branch variable is empty, the reporter uses CI_COMMIT_REF_NAME.

Retrying a job

A retried job stays in its pipeline and keeps CI_PIPELINE_ID - and its job key. When both attempts ran squally-reporter 0.11.0, Squally refuses the retry at its start (ci_run_reused once the first attempt’s run has ended, ci_run_collision while it still runs); with an older reporter, it refuses the retry’s results once the run is complete. Either way the reporter says so once in the job log and sends nothing more. Your job’s exit code is not affected. See Troubleshooting.

Cancelled jobs

Squally shows a run as Cancelled when Playwright itself is interrupted - by SIGINT, as with Ctrl+C - and can still report the end. The reporter has no GitLab-specific handling for a cancelled job, and whether GitLab’s cancel reaches Playwright that way has not been verified. If Playwright is stopped without reporting, the run stays Running until Squally’s hourly check marks it Incomplete. See Cancelled runs.

In practice a cancelled pipeline shows as Incomplete after 60 minutes, the default run timeout. There is no cancel step for GitLab CI as there is for GitHub Actions.