Playwright in CI/CD: GitHub Actions and Sharding
Introduction
Tests only protect you if they run automatically on every change. This final lesson of the course sets up Playwright in GitHub Actions, uploads the HTML report as an artifact, and shows how to shard a large suite across several machines to keep feedback fast.
Prerequisites
- A Playwright project in a GitHub repository
- A package-lock.json committed to the repository
Step-by-Step Guide
Step 1: Create a basic workflow
Save this as .github/workflows/playwright.yml. It installs dependencies, installs browsers with their system dependencies, runs the tests, and always uploads the report.
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
timeout-minutes: 30
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: ${{ !cancelled() }}
with:
name: playwright-report
path: playwright-report/
retention-days: 14Step 2: Provide secrets and settings safely
Store credentials in the repository's encrypted secrets and pass them as environment variables. Never commit passwords or tokens, and keep the saved authentication folder out of Git.
- run: npx playwright test
env:
BASE_URL: https://staging.example.com
APP_USER: ${{ secrets.APP_USER }}
APP_PASSWORD: ${{ secrets.APP_PASSWORD }}Step 3: Split the suite with sharding
Sharding divides the tests into equal parts and runs each part on its own machine. A matrix creates one job per shard, so a long suite finishes in roughly the time of one shard.
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shardIndex: [1, 2, 3, 4]
shardTotal: [4]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}Step 4: Combine the reports
Each shard produces its own results. To get one report, have each shard use the blob reporter, upload it, and merge them in a final job with the merge-reports command.
// in playwright.config.ts for CI
reporter: process.env.CI ? 'blob' : 'html',
// in the final job
npx playwright merge-reports --reporter html ./all-blob-reportsStep 5: Keep CI results trustworthy
Fail the build when a test is accidentally left as test.only by setting forbidOnly in the config. Limit retries, review flaky tests in traces, and run the same browser versions locally and in CI by pinning your Playwright version.
FAQs
- Why use npm ci instead of npm install in CI?
- npm ci installs exactly what is in package-lock.json and fails if the lock file is out of sync, which gives repeatable builds.
- How many shards should I use?
- Start with the number that brings your pipeline under your target time, often 2 to 4. More shards finish faster but cost more machine time and add overhead from installing browsers on each one.
Summary
A short workflow runs your suite on every pull request, an uploaded report makes failures easy to inspect, and sharding keeps a growing suite fast. With this you have a complete Playwright and TypeScript pipeline from first test to CI.
Comments
Log in or create a free account to join the discussion.