GitLab CI uses a single .gitlab-ci.yml file. If your company uses GitLab, this is your setup. GitLab has some nice features -- built-in artifact browsing, merge request widgets, and easy caching.
image: mcr.microsoft.com/playwright:v1.48.0-jammy
stages:
- test
variables:
CI: "true"
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- node_modules/
- ~/.cache/ms-playwright/
playwright-tests:
stage: test
script:
- npm ci
- npx playwright test
artifacts:
when: always
paths:
- playwright-report/
reports:
junit: test-results/results.xml
expire_in: 14 days
timeout: 30mimage: mcr.microsoft.com/playwright:v1.48.0-jammy
stages:
- test
- report
variables:
CI: "true"
.playwright-base:
stage: test
script:
- npm ci
- npx playwright test --shard=$SHARD
artifacts:
when: always
paths:
- blob-report/
expire_in: 1 day
shard-1:
extends: .playwright-base
variables:
SHARD: "1/4"
shard-2:
extends: .playwright-base
variables:
SHARD: "2/4"
shard-3:
extends: .playwright-base
variables:
SHARD: "3/4"
shard-4:
extends: .playwright-base
variables:
SHARD: "4/4"
merge-reports:
stage: report
when: always
needs:
- shard-1
- shard-2
- shard-3
- shard-4
script:
- npm ci
- npx playwright merge-reports --reporter html ./blob-report
artifacts:
when: always
paths:
- playwright-report/
expire_in: 14 days| Feature | GitHub Actions | GitLab CI |
|---|---|---|
| Config file | .github/workflows/*.yml | .gitlab-ci.yml |
| Docker image | container: or docker agent | image: at top level |
| Artifacts | actions/upload-artifact | artifacts: block in job |
| Caching | actions/cache | cache: block with key |
| Sharding | strategy.matrix | parallel: or manual jobs |
| JUnit support | Third-party action | Built-in reports.junit |
| Artifact browsing | Download zip only | Browse in UI directly |
| Merge request widget | Via reporters | Built-in test summary |
GitLab has a built-in JUnit report widget. Add reports.junit to your artifacts and test results show directly in the merge request. No extra plugins needed. This is one area where GitLab has an edge over GitHub.
GitLab CI shared runners have limited resources. If you hit memory issues, either reduce workers in playwright.config.ts or use a self-hosted runner with more resources.
Q: How do you configure Playwright in GitLab CI?
A: Create .gitlab-ci.yml with the Playwright Docker image. Define a test stage that runs npm ci and npx playwright test. Set artifacts with when: always for the HTML report and reports.junit for the JUnit XML. GitLab automatically shows JUnit results in the merge request widget. For sharding, create parallel jobs with different SHARD variables or use the parallel keyword. Use the cache block with node_modules and Playwright browser paths to speed up subsequent runs.
Key Point: GitLab CI uses .gitlab-ci.yml with built-in JUnit and artifact browsing. Use extends and variables for clean sharded configs.
Key Point: GitLab CI has built-in JUnit reporting and artifact browsing. Use the Playwright Docker image and reports.junit for merge request integration.