Building a Playwright CI Template

To make Playwright easy to adopt across many repositories or teams, you can provide a CI template that encodes best practices for parallelism, sharding, retries and reporting. This reduces setup time and keeps pipelines consistent.

Example GitHub Actions Template for Playwright #

A reusable workflow can set up Node, install browsers, run tests in parallel and upload reports. Teams can reference this template with minimal customisation.

# .github/workflows/playwright-template.yml
name: Playwright CI

on:
  workflow_call:
    inputs:
      shardTotal:
        required: false
        type: number
        default: 1
      shardIndex:
        required: false
        type: number
        default: 1

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright browsers
        run: npx playwright install --with-deps

      - name: Run Playwright tests
        env:
          CI: 'true'
        run: npx playwright test --shard=${{ inputs.shardIndex }}/${{ inputs.shardTotal }}

      - name: Upload Playwright report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report-${{ inputs.shardIndex }}
          path: playwright-report

Standardised CI patterns make it easier to roll out improvements like new reporters, stricter flakiness thresholds or additional environments.

Common Mistakes #

Mistake 1 — Letting every team reinvent Playwright CI from scratch #

This wastes effort.

❌ Wrong: Duplicating similar YAML files in dozens of repositories.

✅ Correct: Use a shared template that encodes best practices.

Mistake 2 — Not documenting how the template should be used #

This blocks adoption.

❌ Wrong: Expecting teams to reverse-engineer the workflow by reading YAML only.

✅ Correct: Add clear documentation and examples for common scenarios.