Four Playwright shards each produced their own HTML report - how do you get one report for the whole run?

## Why four reports cannot be added up Each shard is a complete Playwright run over a quarter of the suite, and each reporter it uses produces a finished artefact for that quarter. An HTML report is a rendered site with its own totals, its own trace links and its own index; two of them side by side are two reports, not one. The same holds for JUnit XML: concatenating the files gives a document no CI viewer treats as a single suite. Nothing downstream can reconstruct the whole run from finished outputs, so the fix is to make shards emit something *unfinished* on purpose. ## The blob reporter `blob` is that intermediate. It captures everything a run knows, including test results, steps, attachments, traces and the configuration and project metadata needed to render a report later, and packs it into a zip archive. ```ts import { defineConfig } from '@playwright/test'; export default defineConfig({ reporter: process.env.CI ? 'blob' : 'html', }); ``` Or per invocation, `npx playwright test --shard=1/4 --reporter=blob`. Each shard writes one archive into the `blob-report` directory, and the file name carries the shard number so four jobs writing into a shared location do not collide. ## Collecting and merging The pipeline gathers the four archives into one directory and runs the merge once, after every shard has ended: ```bash npx playwright merge-reports --reporter=html ./all-blob-reports ``` The command reads the directory of archives and replays them through the reporter you name, producing one report as if the suite had run on a single machine. Useful details: - `--reporter` accepts the same reporters a run does, so the same archives can produce `html`, `junit`, `list` or `github` output in one pass or in several. - `--config playwright.config.ts` makes the merge reuse the reporter configuration already in the repository instead of restating options on the command line. - The merge is offline and needs no browsers; it only reads archives. ## What survives the merge | Concern | Four HTML reports | Merged from blob | |---|---|---| | Suite totals | four partial counts | one true count | | Traces and attachments | scattered per shard | present in one report | | Flaky classification | per shard only | across the whole run | | Consumable by CI viewers | four artefacts | one artefact | ## Constraints worth stating in an interview 1. **Same version everywhere.** Archives are tied to the Playwright version that wrote them; a suite pinned to 1.63 must produce and merge all of its archives with 1.63. A shard on a different version is the usual cause of a merge that refuses to run. 2. **Merge after, not during.** The merge job must depend on all shard jobs completing, including failed ones, or the report silently misses a quarter of the suite. 3. **Exit codes are separate from reports.** A merged report showing failures does not by itself fail the pipeline; the shard job outcomes still decide that. 4. **Do not use blob locally.** An archive is not readable by a human; keep `html` or `list` for developer runs and switch to `blob` only where sharding happens. ## Applying it to a payroll suite A payroll regression suite split four ways in CI ends with each job running `--reporter=blob`, publishing its archive, and one final job pulling all four archives together and merging them to HTML. Reviewers open a single report where the pay-cycle failure in one shard and the payslip failure in another sit in the same tree, with their traces attached, and the run's totals are the suite's totals rather than one machine's.