Playwright · Reliable end-to-end tests

How do you run Playwright reliably in CI?

Mediumcigithub actionsartifactsUpdated Oct 2026
Quiz this track

Short answer

Install browsers with dependencies, run headless with CI-aware settings, upload reports and traces, and fail on test.only. Use retries and sharding only after the suite is isolated.

A reliable CI job has deterministic setup, a browser install step, a test command and artifact collection. The most common failures are missing system libraries, a forgotten browser install, an app that is not ready, and reports that disappear when the job fails.

yaml
name: Playwright
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 7
The artifact step runs even when tests fail, so the HTML report and traces are available for diagnosis.

CI checklist

  • Install browsers with --with-deps so OS libraries are present
  • Use CI=1 and disable test.only with the forbidOnly setting
  • Start the app before tests, through webServer or an explicit readiness check
  • Upload the HTML report, traces and screenshots on failure
  • Keep retries low and track flaky tests rather than ignoring them
  • Use a fixed worker count that matches the runner's CPU and memory

If the pipeline runs on a small runner, a high worker count can cause timeouts that look like application bugs. Measure with a realistic worker count and memory limit. Also pin the browser version through the installed Playwright package so local and CI runs use the same engine.

Artifacts can contain session cookies, request bodies and personal data. Restrict who can download them, set a retention period, and avoid uploading auth state files.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Why is the with-deps flag needed?
  2. 2How do you make sure the app is ready before tests start?
  3. 3Why should reports upload even when tests fail?
  4. 4How do you choose a worker count for CI?

Say it in the interview

I install the browsers with the dependency flag, start the app, run the suite with CI-aware settings, and upload the report and traces even when tests fail. I keep retries low, forbid focused tests and choose a worker count the runner can actually handle. Artifacts are essential because a failed job otherwise gives you no evidence. I also treat reports and traces as sensitive because they can contain session data.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Playwright mock interview and get scored feedback on depth, clarity and confidence.