CI/CD Tools
Playwright GitHub Actions YAML Generator
Build a production-ready GitHub Actions workflow for your Playwright tests.
Configure triggers, browsers, matrix and sharding, dependency and browser
caching, retries, artifacts and secrets — then copy or download a ready-to-use
playwright.yml. The preview updates live, and everything runs in your browser.
A real CI pipeline, not a snippet
Wiring Playwright into GitHub Actions by hand means remembering a dozen
small details: pinning action versions, caching the right directories, installing the OS
libraries the browsers need, giving every artifact a unique name for
upload-artifact@v4, and splitting work across shards without losing a single
HTML report. This generator encodes those best practices so the workflow you copy is the
workflow you’d write after reading the docs end to end.
What it generates
- Triggers — push, pull request, manual
workflow_dispatchand a cronschedule, scoped to the branches you list. - Matrix & sharding — run each browser as a project, split the suite across shards, and merge the blob reports into one HTML report.
- Smart caching — setup-node dependency cache plus an
actions/cachefor Playwright browsers, keyed on your lockfile and using the correct per-OS path. - Every package manager — npm, pnpm, yarn or bun with the right install command and setup action.
- Artifacts — HTML report, traces, videos and screenshots uploaded with retention you choose and collision-free names.
- Env & secrets — variables under
env:and secrets as${{ secrets.NAME }}.
How to use it
- Pick a preset (Basic, Enterprise, Monorepo, Nightly or Docker) or configure from scratch.
- Adjust triggers, browsers, caching, retries and artifacts — the preview updates as you type.
- Click Copy or Download to get
playwright.yml. - Commit it to
.github/workflows/playwright.ymland push.
Frequently asked questions
How do I add Playwright tests to GitHub Actions?
Create a file at .github/workflows/playwright.yml in your repository and paste a workflow that checks out the code, sets up Node, installs dependencies, installs the Playwright browsers with "npx playwright install --with-deps", and runs "npx playwright test". This generator builds that file for you with caching, retries, matrix and artifact upload already configured — copy it or download it and commit it to that path.
What is Playwright sharding and when should I use it?
Sharding splits your test suite across several machines that run in parallel, cutting wall-clock time on large suites. Enable it here and the generator emits a matrix with shardIndex/shardTotal plus the official merge-reports job that downloads each shard’s blob report and merges them into a single HTML report. Use it once a full run takes more than a few minutes.
How do I cache Playwright browsers in CI?
Cache the browser download directory (~/.cache/ms-playwright on Linux) with actions/cache, keyed on your lockfile so the cache invalidates when Playwright is upgraded. On a cache hit you still run "npx playwright install-deps" to install the OS libraries, which are not cached. Tick “Cache Playwright browsers” and the generator wires this up correctly, including the per-OS cache path.
Does it support npm, pnpm, yarn and bun?
Yes. Pick your package manager and the workflow uses the right install command (npm ci, pnpm install --frozen-lockfile, yarn install --frozen-lockfile or bun install --frozen-lockfile), adds pnpm/action-setup or oven-sh/setup-bun when needed, and enables setup-node’s built-in dependency cache for the managers that support it.
How do I pass secrets and environment variables to Playwright in CI?
Add environment variables as key/value pairs and secrets by name. Variables are written under the job’s env: block, and each secret becomes NAME: ${{ secrets.NAME }} so GitHub injects it at runtime without exposing the value. Store the secret in your repository or organization settings under Settings → Secrets and variables → Actions.
Is the workflow YAML valid and does my data leave the browser?
The YAML is generated by a builder that controls indentation and structure, so the output is well-formed and follows GitHub Actions best practices (pinned action majors, unique artifact names for upload-artifact@v4, least-privilege patterns). Everything runs locally in your browser — your branch names, secrets and configuration are never uploaded.