Parallel Playwright CI Pipeline with Sharding

GitHub Actions workflow for parallel Playwright test execution with sharding, retries, and artifact upload.

Who this is for

SDETs and QA engineers who want to significantly reduce their Playwright test suite execution time by running tests in parallel shards across CI workers — especially for suites with more than 50 tests.

Prompt Template

You are a DevOps engineer specialising in CI/CD pipelines for test automation.

Generate a maintainable GitHub Actions workflow for running Playwright tests with:
- Project: {{projectName}}
- Runner OS: {{runnerOS}} (ubuntu-latest recommended)
- Node version: {{nodeVersion}}
- Shard count: {{shardCount}} (e.g., 4 for 4 parallel shards)
- Browsers: {{browsers}} (chromium, firefox, webkit)

Requirements:
1. Matrix strategy for parallel sharding across {{shardCount}} runners
2. Dependency caching for node_modules and Playwright browsers
3. Retry failed tests up to 2 times (--retries 2)
4. Upload test results and HTML report as artifacts on failure
5. Merge shard reports into a single HTML report
6. Fail-fast disabled so all shards complete
7. Environment variables injected from GitHub Secrets
8. Conditional steps: only upload artifacts on failure
9. Cache key based on package-lock.json hash
10. Post-run step to comment results on PR (optional)

Include the full workflow YAML with clear comments on each step.

How to use this prompt

1Copy the prompt and specify your CI platform (GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins).
2Indicate your shard count target (e.g. 4 shards for a 200-test suite to get ~4× speedup).
3Provide your Playwright version and any existing workflow structure you want to preserve.
4The AI generates a complete parallel CI configuration with shard coordination, merged HTML reporting, and retry logic.
5Commit the workflow file and monitor the first run to confirm shard distribution is even.

Example output

A GitHub Actions workflow with a matrix of 4 shards using `--shard=1/4` through `--shard=4/4`, dependency caching with `~/.cache/playwright`, HTML report upload as an artifact on each shard, a merge job that combines all shard reports into a single HTML report, and automatic retry on failure for up to 2 retries.

Limitations

Sharding distributes tests by file — if your test files are very large (>50 tests each), the shard distribution may be uneven. Split large test files for optimal parallelism.
CI runner cost scales with shard count — more shards means faster tests but higher compute cost. Profile your suite before setting a high shard count.
Some tests with shared state (e.g. a single test user account) may fail when run in parallel — use fixtures with isolated accounts per shard.

CI/CD Pipeline Architect

playwright professional

Frequently asked questions

How many shards should I use?v

A good rule of thumb is one shard per 50 tests, up to the number of CPU cores available on your CI runner. More than 8 shards rarely improves speed significantly due to coordination overhead.

How do I merge HTML reports from multiple shards?v

Playwright's built-in `merge-reports` command combines shard blob reports into a single HTML report. The generated CI config includes an explicit merge job that downloads all shard artifacts and runs this command.

Can I use this with Playwright's built-in parallelism instead?v

Playwright's `--workers` flag parallelises within a single machine. Sharding distributes across multiple CI machines — use both together for maximum speed: set workers per shard and shards across machines.