What does Playwright change about a run when the CI environment variable is set?

## What the variable actually switches Playwright reads the conventional `CI` environment variable — the one virtually every CI provider sets for you inside a job — and uses it to pick a different **default reporter**. With no reporter declared in `playwright.config.ts` or on the command line: - locally, you get `list`, which prints a line per test as it runs and rewrites it with the result; - with `CI` set, you get `dot`, which prints one character per test. That is the switch itself. It is a default, so it evaporates the moment your config names a reporter — which is what most real projects do — and it applies to output only. No test selection, no timing, no parallelism changes because the variable is present. ## Why the default flips at all Interactive output assumes a terminal that can redraw lines. A CI log is an append-only stream: every redraw becomes another line, so a `list` run of a large payroll regression suite produces a log with thousands of near-duplicate lines that is slow to load and hard to scan. `dot` writes one character per test result and a failure block at the end. The signal you want in a CI log — how many, which ones failed, and the failure text — survives; the progress animation that only makes sense on a live terminal does not. | | `list` (local default) | `dot` (CI default) | |---|---|---| | Output per test | A line, rewritten in place on completion | A single character | | Suits | A live terminal | An append-only log stream | | Failure detail | Printed at the end | Printed at the end | ## What it does *not* do This is the part interviews probe, because the mental model "setting CI makes Playwright CI-ready" is wrong and expensive: - It does **not** decide worker count, retries, or whether a stray focused test fails the run. Those are config options; if your config does not set them, `CI` changes nothing about them. - It does **not** install browsers or system dependencies. - It does **not** change the exit code contract or where artefacts are written. The reason people believe otherwise is the generated starter config, which branches on `process.env.CI` for several options. That is **your** code doing the switching, not the runner: the scaffolding writes those ternaries so the same config behaves differently in the two places. Read the config and you can see exactly which behaviours are yours and which are the framework's. ## Using it deliberately 1. Set the reporter explicitly in `playwright.config.ts` if the choice matters to you, rather than depending on a default that changes with the environment. A run whose output shape depends on an ambient variable is a run that surprises whoever reads the log next. 2. If your config branches on `process.env.CI`, keep every branch in one place so a reader sees the whole local-versus-CI delta at once. 3. Set `CI=1` yourself when you want CI behaviour on a workstation — for example reproducing a colleague's log format — and unset it in a container you are debugging interactively, where the live `list` output is more useful. 4. Do not *unset* it in a real CI job to get prettier output; you get a much larger log and no other benefit. ## Reading a dot run Each character is a result, so a wall of dots with a few marks in it tells you the run's shape at a glance, and the detail you actually need — the failing tests, their errors and the summary counts — comes after. If a team finds that unreadable, the answer is to name a reporter in the config, not to fight the environment variable. That also makes the choice reviewable: a reporter in version control is a decision someone made, while a default that flips on an ambient variable is a decision nobody made.