Running Playwright Tests in GitHub Actions
A practical CI setup for Playwright: fast feedback on every pull request, sharding for large suites, and reports and traces you can actually debug from.
By russellazim
2 min read
Automation only pays off when it runs on every change, automatically, and tells the team something useful within minutes. GitHub Actions makes that straightforward for Playwright — if a few details are right from the start.
A minimal workflow that works
Install dependencies from the lockfile, install only the browsers you need, run the tests and always upload the report — especially when something fails.
name: e2e
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22, cache: npm }
- run: npm ci
- run: npx playwright install --with-deps chromium
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/Keep pull-request feedback fast
- Run a focused set on pull requests — smoke and critical-path tests tagged
@critical— and the full cross-browser suite on merge or nightly. - Shard large suites across parallel jobs with
--shard=1/4and a matrix strategy. - Cache npm, not browsers. Browser downloads are fast and caching them often causes version mismatches.
Make CI failures debuggable
Use trace: 'on-first-retry' and upload the HTML report as an artifact. A trace shows every action, network call and DOM snapshot, which turns “works on my machine” arguments into a five-minute investigation.
Secrets and environments
Store credentials as repository or environment secrets and pass them as environment variables. Never commit test accounts to the repository, and use dedicated test users with the minimum permissions they need.
Make it a quality gate
Mark the workflow as a required status check on the main branch. Once tests block merges, flaky tests become everyone’s problem — which is exactly what gets them fixed.
