Run Playwright API Tests in CI: GitHub Actions, Allure and JUnit

Tests that only run on your laptop protect nobody. The real value of an API suite appears when it runs automatically on every pull request, blocks broken builds, and publishes a report the whole team can read. In this final lesson of Module 6 you’ll run the Playwright API framework in GitHub Actions with secrets, tags, sharding and type-checking, produce HTML, JUnit and Allure reports, and see the equivalent Jenkins pipeline.

What a Good API Test Pipeline Does

1. Triggers on pull requests, merges to main, a nightly schedule and manual runs.
2. Installs exact dependency versions (npm ci with a lockfile).
3. Type-checks the test code (Playwright doesn’t).
4. Runs the right subset: smoke on PRs, full regression nightly or on merge.
5. Fails the build on test failures (non-zero exit code).
6. Publishes reports as artifacts and test results in the CI UI.
7. Keeps secrets secret: credentials from the secret store, never in Git or logs.

Prepare the Project for CI

Scripts in package.json keep commands identical locally and in CI:

{
  "scripts": {
    "typecheck": "tsc -p tsconfig.json --noEmit",
    "test": "playwright test",
    "test:smoke": "playwright test --grep @smoke",
    "report": "playwright show-report"
  }
}

Tag your critical tests. The tag syntax (Playwright 1.42+):

import { test, expect } from '@playwright/test';
test('health is up', { tag: ['@smoke', '@health'] }, async ({ request }) => { await expect(await request.get('health')).toBeOK(); });

The config from the framework lesson already sets forbidOnly, retries and workers when process.env.CI is set; GitHub Actions and most CI tools set CI=true automatically.

GitHub Actions Workflow

Save as .github/workflows/api-tests.yml:

name: API tests

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '30 1 * * *'          # nightly 01:30 UTC (07:00 IST)
  workflow_dispatch:

jobs:
  api-tests:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2]               # split the suite across 2 machines
    env:
      API_BASE_URL: ${{ vars.API_BASE_URL }}
      ADMIN_USER: ${{ secrets.ADMIN_USER }}
      ADMIN_PASS: ${{ secrets.ADMIN_PASS }}
      VIEWER_USER: ${{ secrets.VIEWER_USER }}
      VIEWER_PASS: ${{ secrets.VIEWER_PASS }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run typecheck
      # Pull requests run the smoke subset; everything else runs the full suite
      - name: Run tests
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            npx playwright test --grep @smoke --shard=${{ matrix.shard }}/2
          else
            npx playwright test --shard=${{ matrix.shard }}/2
          fi
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: report-shard-${{ matrix.shard }}
          path: |
            playwright-report/
            results/junit.xml
            allure-results/
          retention-days: 14

Notes on the important lines:

• No npx playwright install: pure API tests don’t launch browsers, which saves a minute or more per job. Add it back when the suite includes UI tests.
• vars vs secrets: non-sensitive values (base URL) as repository variables; passwords and tokens as secrets (masked in logs).
• if: always() uploads reports even when tests fail, which is exactly when you need them.
• fail-fast: false lets every shard finish so you see all failures.

Create secrets under Settings → Secrets and variables → Actions. Practice API credentials are public, but use secrets anyway to build the habit.

Sharding: Split Long Suites

--shard=1/4 runs the first quarter of tests, 2/4 the second, and so on. Run each shard on a separate CI machine in parallel. Locally, the framework from this module splits into 28 and 27 tests with --shard=1/2 and --shard=2/2. To combine shard results into one HTML report, use the blob reporter in each shard and npx playwright merge-reports in a final job:

# in each shard
npx playwright test --shard=1/4 --reporter=blob
# in a final job, after downloading all blob-report folders into all-blob-reports/
npx playwright merge-reports --reporter=html ./all-blob-reports

Reports: HTML, JUnit and Allure

Adding Allure

npm install -D allure-playwright
# run with the Allure reporter (or add ['allure-playwright'] to the reporter list in the config)
npx playwright test --reporter=line,allure-playwright
# generate and open the report (needs the Allure command-line tool, which requires Java)
npx allure generate allure-results --clean -o allure-report
npx allure open allure-report

The allure-playwright reporter writes JSON result files into allure-results/; we verified it produced one result file per test for this framework. Allure’s history and trend charts need the previous report’s history folder copied into allure-results before generating, which hosted setups (Allure TestOps, or a GitHub Pages workflow) do for you.

Jenkins Pipeline

Many service companies run Jenkins. The same steps in a declarative Jenkinsfile:

pipeline {
  agent { docker { image 'node:22' } }
  environment {
    API_BASE_URL = 'https://qa.example.com/api/v1/'
    ADMIN        = credentials('qa-admin')        // creates ADMIN_USR and ADMIN_PSW
  }
  triggers { cron('H 1 * * *') }
  stages {
    stage('Install')   { steps { sh 'npm ci' } }
    stage('Typecheck') { steps { sh 'npm run typecheck' } }
    stage('Test') {
      steps {
        sh 'ADMIN_USER=$ADMIN_USR ADMIN_PASS=$ADMIN_PSW npx playwright test'
      }
    }
  }
  post {
    always {
      junit 'results/junit.xml'
      archiveArtifacts artifacts: 'playwright-report/**', allowEmptyArchive: true
    }
  }
}

Jenkins’ junit step turns the JUnit XML into test trends and per-test history. More details are in the Playwright Jenkins lesson and the GitHub Actions tutorial.

Keeping CI Green (and Trustworthy)

• Flaky tests: track tests that pass on retry (HTML report marks them “flaky”); fix or quarantine with test.fixme() plus a ticket. Never just raise retries.
• Environment health first: a setup project that logs in also acts as a health gate; if it fails, the run stops with one clear error.
• Test data hygiene: unique data and cleanup so parallel CI jobs don’t collide.
• Fast feedback: smoke on PRs in under 5 minutes; heavier suites on merge or nightly.
• Notifications: send failures to the team’s Slack or Teams channel with a link to the report.
• Ownership: a failing pipeline is everyone’s priority, not “QA’s problem”.

Module 6 Recap

The full framework from this module (55 tests including setup) passes against the live practice API. Next, Module 7 turns these skills into five portfolio projects.

Interview Questions: CI/CD for API Tests