playwright-ci

Configure Playwright test pipelines for GitHub Actions, GitLab CI, CircleCI, Azure DevOps, and Jenkins.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/bilacchi/agents-skills --skill playwright-ci-bilacchi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: playwright-ci
Source: https://github.com/bilacchi/agents-skills/tree/main/skills/playwright-skill/ci
Command: npx skills add https://github.com/bilacchi/agents-skills --skill playwright-ci-bilacchi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Setting up Playwright end-to-end tests in CI/CD pipelines involves many pitfalls: slow runs without sharding, missing browser dependencies, lost test reports, and flaky behavior that only appears in CI. This Skill provides copy-paste-ready configurations and troubleshooting guidance for running Playwright reliably across all major CI platforms. ## Core Features & Use Cases - CI Provider Configurations: Production-ready pipeline templates for GitHub Actions, GitLab CI, CircleCI, Azure DevOps, and Jenkins, including caching, secrets, and artifact handling. - Parallel Execution & Sharding: Split test suites across multiple runners with --shard, then merge blob reports into a single unified HTML report. - Docker & Containers: Run tests in the official Playwright Docker images, compose full application stacks with databases, and extract reports from containers. - Reporting, Coverage & Setup: Configure reporters, JUnit integration, code coverage, and global setup/teardown for auth state and database seeding. - Use Case: Your Playwright suite takes 25 minutes on every pull request. Use this Skill to shard it across 4 GitHub Actions runners, cache browser binaries, and merge results into one HTML report, cutting feedback time to under 10 minutes. ## Quick Start Set up a sharded Playwright test workflow for GitHub Actions with browser caching and merged HTML reports.

Frequently Asked Questions about playwright-ci

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run Playwright tests in GitHub Actions?▼

Create a workflow that checks out the repo, sets up Node.js, caches the ~/.cache/ms-playwright directory keyed on package-lock.json, installs browsers with npx playwright install --with-deps, and runs npx playwright test. Upload the playwright-report folder as an artifact for later inspection.

How to shard Playwright tests across multiple CI runners?▼

Use the --shard=N/M CLI flag with a CI matrix strategy so each runner executes a fraction of the suite. Configure the blob reporter in CI, upload each shard's blob-report as a uniquely named artifact, then run npx playwright merge-reports in a downstream job to produce one HTML report.

Which Docker image should I use for Playwright in CI?▼

Use the official image mcr.microsoft.com/playwright:v<version>-noble, matching the tag exactly to your @playwright/test version. It ships with all browsers and OS dependencies pre-installed, eliminating browser install time in pipelines.

Why do Playwright tests pass locally but fail in CI?▼

CI runners typically have fewer CPU cores and less memory, so default timeouts and worker counts are too aggressive. Reduce workers to 50% in CI and raise actionTimeout and navigationTimeout, and ensure OS dependencies are installed with npx playwright install-deps when using cached browsers.

How do I share login state across Playwright tests in CI?▼

Authenticate once in a setup project or globalSetup, save the session with page.context().storageState(), and reference that file in each project's use.storageState config. Dependent test projects then reuse the signed-in state without logging in again.

When should I avoid sharding Playwright tests?▼

Avoid sharding when the suite runs in under 5 minutes, because per-shard overhead like checkout, dependency install, and report merging exceeds the time saved. Sharding pays off for suites exceeding 10 minutes, typically with 2 to 8 shards.