Playwright Test Sharding Creates Too Many CI minutes

[matthewkrausse]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched in the documentation/README.
• I already searched in Google "How to do X" and didn't find any information.
• I already read and followed all the tutorial in the docs/README and didn't find an answer.

Commit to Help

• I commit to help with one of those options 👆

Example Code

see github action minutes

Description

I don't see the playwright tests being sharded and running on every pull and push to be needed. I moved to just PRs on ym major release or main branches. Also moved to one shard. Running 4 just increases the ci minutes by 4 and doesn't really speed up the process of wall time. Just wanted to see what people though before I submitted a PR to undo this. I think that this is costing people money needlessly for no good benefit unless you have hundreds of tests.

Operating System

Linux

Operating System Details

gh ci runners

Python Version

3.13

Additional Context

No response

[FransuaLeonSanchez]

I would not remove the coverage or hard-code a single shard globally, but I agree that four Playwright shards on every push can be wasteful when the suite is small. The useful decision is based on wall-clock time versus runner minutes.

A compromise I have used for CI-heavy projects:

• Keep fast unit/API checks on every pull request.
• Run the Playwright job on pull requests and the default branch, but make the shard count configurable (1 shard by default, 4 for release or manual runs).
• Use path filters if the workflow allows it, so documentation-only or backend-only changes do not start browser tests unnecessarily.
• Keep a scheduled full run with the maximum shard count so coverage is still exercised regularly.
• Cache the package-manager and Playwright browser downloads; otherwise each shard repeats the same setup cost.
• Compare both total billable minutes and time to feedback before changing the default.

For this template, one shard as the default sounds reasonable if the current Playwright suite does not noticeably reduce wall time with four shards. I would keep the matrix in the workflow, though, so maintainers can increase it as the suite grows instead of revisiting the CI design later. The important part is reducing redundant parallel setup, not reducing test coverage.