Q10 of 38 · CI/CD & DevOps

How do you set up Cypress (or Playwright) in GitHub Actions with reporting?

CI/CD & DevOpsMidci-cdplaywrightcypressgithub-actionse2e

Short answer

Short answer: Use the official action (cypress-io/github-action or installed Playwright), cache npm and browser binaries, run with sharding, upload HTML reports + traces/videos as artifacts on failure, and post a summary comment with screenshot links so reviewers don't have to download artifacts.

Detail

Three core concerns: speed (cache and shard), reliability (start the app, wait for ready), and visibility (artifacts and PR comments).

Speed:

  • Cache ~/.npm keyed on lockfile hash.
  • Cache browser binaries (~/.cache/Cypress for Cypress, ~/.cache/ms-playwright for Playwright). Saves 60-90 seconds per run.
  • Shard: matrix strategy with [1, 2, 3, 4] and pass --shard 1/4 (Playwright) or use @cypress/grep / merge tools (Cypress) to split spec files.

Reliability:

  • Start the app under test as a step (npm run dev & or via the action's start parameter).
  • Use wait-on or the action's wait-on flag to block until the app is reachable. Don't sleep.
  • Set per-job timeout — defaults are too generous and can hold the queue.

Visibility:

  • Upload if: failure() artifacts: cypress/videos, cypress/screenshots, playwright-report, test-results (traces).
  • Use actions/upload-artifact@v4 with retention 7-14 days.
  • For PR comments, use a reporter (e.g. mochawesome, Playwright's HTML report) and post via actions/github-script. The reviewer should see "3 tests failed: login.spec.ts:42, checkout.spec.ts:88" without leaving the PR.

Reporting tools that pay off:

  • Cypress Cloud / Currents.dev — paid, best for parallelism and history.
  • Playwright HTML report + traces — free, excellent for debugging individual failures.
  • Allure — heavier, prettier; good for status reports to non-engineers.

Failure-mode discipline: don't retry-on-fail by default at the spec level. Quarantine flakes; let real failures fail. Auto-retry hides the bugs you're paying CI to find.

// EXAMPLE

.github/workflows/e2e.yml

name: E2E
on: [pull_request]
jobs:
  playwright:
    runs-on: ubuntu-latest
    strategy:
      matrix: { shard: [1, 2, 3, 4] }
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --shard=${{ matrix.shard }}/4
        env: { BASE_URL: ${{ secrets.STAGING_URL }} }
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report-${{ matrix.shard }}
          path: playwright-report/
          retention-days: 14

// WHAT INTERVIEWERS LOOK FOR

Caching, sharding, app-readiness pattern (no sleeps), failure-only artifact upload, and PR-comment reporting. Bonus for naming retry hygiene.

// COMMON PITFALL

Setting `continue-on-error: true` to make the job green when tests fail. The pipeline is now decorative — it doesn't gate anything.

// Related questions

How would you integrate Selenium tests into a Jenkins pipeline with reporting?

Selenium

How do you parallelise your test suite to keep CI runs under 10 minutes?

CI/CD & DevOps

What is a build pipeline?

CI/CD & DevOps

How would you integrate Karate with CI (Jenkins, GitHub Actions) including parallel execution?

Karate