CTCaliberTek
Course: Playwright with TypeScript: End to End · Lesson 9 of 9Log in to track your progress and earn a certificate when you finish the course.
Software Testing

Playwright in CI/CD: GitHub Actions and Sharding

Published September 12, 2026·Updated October 29, 2026·9 min read
Like SaveLog in to like, save, and track progress.

Introduction

Tests only protect you if they run automatically on every change. This final lesson of the course sets up Playwright in GitHub Actions, uploads the HTML report as an artifact, and shows how to shard a large suite across several machines to keep feedback fast.

Prerequisites

  • A Playwright project in a GitHub repository
  • A package-lock.json committed to the repository

Step-by-Step Guide

Step 1: Create a basic workflow

Save this as .github/workflows/playwright.yml. It installs dependencies, installs browsers with their system dependencies, runs the tests, and always uploads the report.

name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 14

Step 2: Provide secrets and settings safely

Store credentials in the repository's encrypted secrets and pass them as environment variables. Never commit passwords or tokens, and keep the saved authentication folder out of Git.

      - run: npx playwright test
        env:
          BASE_URL: https://staging.example.com
          APP_USER: ${{ secrets.APP_USER }}
          APP_PASSWORD: ${{ secrets.APP_PASSWORD }}

Step 3: Split the suite with sharding

Sharding divides the tests into equal parts and runs each part on its own machine. A matrix creates one job per shard, so a long suite finishes in roughly the time of one shard.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shardIndex: [1, 2, 3, 4]
        shardTotal: [4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

Step 4: Combine the reports

Each shard produces its own results. To get one report, have each shard use the blob reporter, upload it, and merge them in a final job with the merge-reports command.

// in playwright.config.ts for CI
reporter: process.env.CI ? 'blob' : 'html',

// in the final job
npx playwright merge-reports --reporter html ./all-blob-reports

Step 5: Keep CI results trustworthy

Fail the build when a test is accidentally left as test.only by setting forbidOnly in the config. Limit retries, review flaky tests in traces, and run the same browser versions locally and in CI by pinning your Playwright version.

FAQs

Why use npm ci instead of npm install in CI?
npm ci installs exactly what is in package-lock.json and fails if the lock file is out of sync, which gives repeatable builds.
How many shards should I use?
Start with the number that brings your pipeline under your target time, often 2 to 4. More shards finish faster but cost more machine time and add overhead from installing browsers on each one.

Summary

A short workflow runs your suite on every pull request, an uploaded report makes failures easy to inspect, and sharding keeps a growing suite fast. With this you have a complete Playwright and TypeScript pipeline from first test to CI.

Related tutorials

Comments

Log in or create a free account to join the discussion.

  • No comments yet. Be the first to comment.