GitHub Actions × Playwright: Automate E2E Tests in CI/CD | Complete Setup Guide from Scratch

By combining GitHub Actions with Playwright, you can build a CI/CD pipeline that automatically runs E2E tests on every push — at no extra cost.

Even if tests pass locally, it’s common for someone’s push to break things unexpectedly. By integrating E2E tests into CI/CD, you can build a system where tests run automatically on every push and you get notified the moment something fails. This article walks you through building a working CI/CD pipeline with GitHub Actions × Playwright × pytest — completely from scratch.

CI/CD and GitHub Actions: The Basics

CI (Continuous Integration) is a practice where builds and tests are triggered automatically whenever code is pushed or a PR is opened. GitHub Actions is GitHub’s built-in CI/CD service — all you need to do is create a .github/workflows/ folder in your repository and add a YAML file.

① Project Structure

Here’s the project structure we’ll be working with.

my_project/
├── .github/
│   └── workflows/
│       └── playwright.yml    # GitHub Actions workflow file
├── tests/
│   ├── conftest.py
│   └── test_saucedemo.py     # Playwright tests
├── requirements.txt          # Package dependencies
└── pytest.ini                # pytest configuration

② Setting Up requirements.txt

List the packages to install in the CI environment in requirements.txt.

pytest
pytest-playwright
pytest-html
playwright

③ Test Code Overview

Here’s the sample Playwright test that will run in CI. It tests the SauceDemo login flow.

# tests/test_saucedemo.py
from playwright.sync_api import Page

def test_login_success(page: Page):
    page.goto("https://www.saucedemo.com/")
    page.fill("#user-name", "standard_user")
    page.fill("#password", "secret_sauce")
    page.click("#login-button")
    assert page.url.endswith("/inventory.html")

def test_login_wrong_password(page: Page):
    page.goto("https://www.saucedemo.com/")
    page.fill("#user-name", "standard_user")
    page.fill("#password", "wrong_password")
    page.click("#login-button")
    error_msg = page.locator(".error-message-container").text_content()
    assert "Epic sadface" in error_msg

# pytest.ini
[pytest]
testpaths = tests
addopts = -v --tb=short --html=reports/report.html --self-contained-html

④ Creating the GitHub Actions YAML File (Core)

This is the heart of the setup. Create .github/workflows/playwright.yml with the following content.

# .github/workflows/playwright.yml

name: Playwright E2E Tests

# ① Trigger: run automatically on push to main or on PRs
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    # ② Runner: use the latest Ubuntu
    runs-on: ubuntu-latest

    steps:
      # ③ Check out the repository code
      - name: Checkout repository
        uses: actions/checkout@v4

      # ④ Set up Python
      - name: Set up Python 3.11
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      # ⑤ Install dependencies (upgrade pip first for stability)
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      # ⑥ Install Playwright browsers
      - name: Install Playwright browsers
        run: playwright install chromium --with-deps

      # ⑦ Create reports folder (prevents artifact upload failure)
      - name: Create reports folder
        run: mkdir -p reports

      # ⑧ Run tests
      - name: Run E2E tests
        run: pytest

      # ⑨ Upload test report as artifact
      - name: Upload report
        uses: actions/upload-artifact@v4
        if: always()    # run even if tests fail
        with:
          name: playwright-report
          path: reports/
          retention-days: 30

Here’s what each step does:

⑤ How to Check the Results

Once you push the YAML file to GitHub, the workflow starts automatically. Here’s how to check the results.

Sample Execution Log

Run pytest
========================= test session starts ==========================
platform linux -- Python 3.11.0, pytest-7.4.0
collected 2 items

tests/test_saucedemo.py::test_login_success        PASSED  [ 50%]
tests/test_saucedemo.py::test_login_wrong_password PASSED  [100%]

========================== 2 passed in 8.43s ===========================

⑥ Advanced: Scheduled Runs & Multi-Browser Testing

Run tests automatically every night

If you want tests to run on a schedule rather than just on push, add a schedule trigger.

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  schedule:
    - cron: "0 0 * * *"   # every day at UTC 00:00 (midnight)

Run tests in parallel across multiple browsers

Using strategy: matrix, you can run tests in parallel across Chromium, Firefox, and WebKit.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        browser: [chromium, firefox, webkit]

    steps:
      # ... same as before ...

      - name: Install Playwright browsers
        run: playwright install ${{ matrix.browser }} --with-deps

      - name: Run E2E tests (${{ matrix.browser }})
        run: pytest --browser ${{ matrix.browser }}

      - name: Upload report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: report-${{ matrix.browser }}
          path: reports/

FAQ

⚠️ 8 Common Pitfalls with GitHub Actions × Playwright

CI environments come with their own unique set of headaches, especially with GitHub Actions × Playwright. Here are the issues most likely to catch you off guard — knowing them in advance will save you a lot of frustrating debugging.

# With caching enabled (cache is auto-invalidated when requirements.txt changes)
- uses: actions/setup-python@v5
  with:
    python-version: "3.11"
    cache: "pip"          # cache is cleared automatically when requirements.txt hash changes

# Without caching (clean install every run)
- uses: actions/setup-python@v5
  with:
    python-version: "3.11"
    # omitting cache means no caching (fresh install every time)

📋 Summary

Integrating E2E tests into CI/CD means quality is guaranteed no matter who pushes code. Start with a simple setup — Chromium only, main branch only — and expand to scheduled runs and multi-browser testing as you get comfortable.