How to Run Playwright Tests in CI/CD

Writing Playwright tests is only half the value. The payoff comes when they run automatically on every change — in your CI/CD pipeline — so a broken journey is caught before it reaches production. This guide covers the pipeline shape, what to get right for speed and reliability, and a concrete starter setup.

What "running in CI" actually means

CI/CD (continuous integration / continuous delivery) is the automated pipeline that builds and checks your code whenever someone pushes a change. Adding Playwright to it means: on each push or pull request, the pipeline installs the browsers, runs your test suite against a deployed or locally started version of the app, and reports a pass or fail back to the pull request. A failing run blocks the merge.

The basic pipeline steps

Regardless of which CI system you use, the shape is the same:

1. Check out the code and install dependencies
2. Install the Playwright browsers (a single command)
3. Start or point at the application under test
4. Run the test suite
5. Publish the results and any traces or reports as artifacts

Playwright runs in any CI system — GitHub Actions, GitLab CI, CircleCI, Jenkins, and others. GitHub Actions and GitLab CI are the most common, and Playwright provides ready-made workflow templates to get started quickly.

A minimal GitHub Actions example

A typical pull-request job looks like this in spirit (exact YAML varies by monorepo layout):

1. Use a Node version that matches local development, then npm ci (or your package manager's lockfile install).
2. Run npx playwright install --with-deps once, then cache the browser download between runs so every PR is not a cold download.
3. Start the app (or point baseURL at a preview deploy), then run npx playwright test.
4. On failure, upload the HTML report and trace.zip artifacts so anyone can open the trace viewer without reproducing locally.

Keep secrets (staging credentials, API keys) in the CI secret store — never in the repo — and give the job only the env vars the suite needs.

Getting it right: speed

A slow suite that adds twenty minutes to every pull request will get disabled. Keep CI runs fast:

• Run in parallel. Playwright parallelizes across workers automatically. For larger suites, shard across machines so wall-clock time stays short. This is the core problem our runner infrastructure solves.
• Cache the browser install. Downloading browsers on every run is wasteful — cache them between builds.
• Cover journeys as flows, not fragments. A focused suite of complete journeys runs faster and means more than hundreds of shallow tests, as we explain in flows vs. tests.
• Split smoke vs. full suite. Run a tagged smoke set on every PR; run the full suite on main or on a schedule so PR feedback stays minutes, not hours.

Getting it right: reliability

CI is exactly where flaky tests do the most damage, because a random failure blocks an unrelated change and trains everyone to ignore red builds. To keep CI trustworthy:

• Keep every test isolated so it can run in any order, in parallel
• Capture a trace on failure so you can debug without re-running locally
• Use a small, bounded number of retries for genuine infrastructure blips — not as a way to hide flakiness (see from flaky to stable)
• Control test data and external dependencies so runs are repeatable

Gating deployments

The real power of E2E tests in CI is using them as a gate: a deployment only proceeds if the critical-journey tests pass. Many teams tag a subset of tests — a smoke test — to run as a fast pre-deploy check, with the full suite running on a schedule or before release. Our CLI is built for exactly this: trigger flows by tag from your pipeline and block the deploy on failures.

Common mistakes

• No artifacts on failure — without traces and reports, every red build becomes a local reproduction scavenger hunt.
• Retries as a flake strategy — retries mask bad selectors and timing; they do not fix them.
• Shared mutable staging data — parallel workers collide and create order-dependent failures that look like product bugs.
• Treating CI as optional — if merges go through red E2E, the suite is documentation, not a gate.

The maintenance reality

A CI suite is living infrastructure. Browsers update, your UI changes, and tests need upkeep to stay green for the right reasons. Standing up the pipeline is the easy part; keeping it fast and trustworthy over months is the ongoing work — and a common reason teams use managed QA.

QA Guardian runs your suite on scalable parallel infrastructure, integrates results into your pipeline, and keeps everything green for real reasons — while handing you standard Playwright code you own. Book a demo to see it wired into your own CI.