Running Playwright Tests in CI/CD: A Practical Setup Guide

Why CI integration is non-negotiable

A test suite that engineers run manually when they remember to is a test suite that will miss regressions. Manual test runs are skipped when deadlines are tight, when a change 'looks safe', or simply because the habit is not established. Automated CI runs have no such exceptions.

The moment your Playwright tests run on every pull request, the relationship between the team and the test suite changes. Failures are caught before merge, not after deploy. The suite becomes a gating signal rather than an afterthought.

Setting up Playwright in GitHub Actions

GitHub Actions is the most common CI environment for Playwright. The official `microsoft/playwright-github-action` handles browser installation, but most teams install browsers as part of the npm install step using `npx playwright install --with-deps`.

The key decisions in your workflow file are: which branches trigger the run, whether to run in parallel across multiple workers, and how to handle test artifacts like screenshots and traces on failure.

• Use `npx playwright install --with-deps chromium` to install only the browser you need — faster than installing all three
• Upload test results and screenshots as artifacts on failure for easy debugging
• Cache `~/.cache/ms-playwright` to avoid re-downloading browsers on every run
• Use `--reporter=github` in CI for inline PR annotations when tests fail

Handling authentication in CI

The most common CI setup challenge is authentication. Most applications require a logged-in user to test anything meaningful, and going through the login UI before every test is slow and fragile.

Playwright's `storageState` feature solves this cleanly. Run a setup script once that logs in and saves the browser storage state to a file. All subsequent tests load that state instead of repeating the login flow. This is faster and more reliable than login-per-test.

Store test credentials as CI secrets, not in the repository. Pass them to the Playwright process via environment variables referenced in your config.

Managing test environments

Playwright tests need to run against a live application. In CI, you have three options: run against a preview deployment that your CI pipeline creates automatically (the cleanest approach for most teams), run against a staging environment that is always live, or spin up the application as part of the CI job.

Preview deployments are the most reliable pattern. Services like Vercel, Netlify, and Render create them automatically on pull requests. Your Playwright workflow can wait for the deployment to be ready, then run tests against that specific preview URL.

How Assert integrates with CI

Assert is designed to run in CI as naturally as running locally. Commit `assert.config.json` to the repo, install the Assert CLI in your pipeline, and run `assert`. The service reads your Markdown scenarios, generates the Playwright tests, executes them in your pipeline environment, and posts results to the Assert dashboard.

This means CI results, pass/fail history, failure screenshots, and step-level detail are all available in the dashboard without any additional reporting setup. The pipeline just needs to run the CLI.

FAQ