Speed up Playwright tests in GitHub Actions

Playwright's trace and video recorders write to disk while the suite runs and the upload-artifact step then has to compress and transfer whatever they produced. When trace or video is set to "on", that recording and upload happens on every run regardless of outcome, so a suite that passes ninety-nine times out of a hundred still writes and uploads ninety-nine sets of traces and videos that exist only to be deleted by the artifact retention window. on-first-retry and retain-on-failure record only when a test actually needs debugging, and the CI job itself only writes an upload-artifact step conditioned on failure() so passing runs skip the step's own overhead too.

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: test-results
          path: test-results/

1. 01

   Search Playwright config for unconditional capture: grep -n 'trace:\|video:\|screenshot:' playwright.config.* - a value of 'on' (rather than 'on-first-retry', 'retain-on-failure', or 'only-on-failure') means every run records, pass or fail.

2. 02

   Search the workflow for the upload step: grep -n 'actions/upload-artifact' -A5 .github/workflows/*.yml - check whether the step has an if: failure() (or if: always() deliberately paired with a failure-only trace config) guarding it; an unconditioned upload step runs after passing jobs too.

3. 03

   Search for the browser install step: grep -n 'playwright install' .github/workflows/*.yml - a bare npx playwright install --with-deps with no browser argument installs Chromium, Firefox, and WebKit even when the suite only targets one.

• -

  on-first-retry only records once a test has already failed once and is being retried, so it needs retries configured above zero; with retries at zero, on-first-retry never fires and a failing test produces no trace at all.

• -

  A flaky test that fails once and passes on retry still leaves no trace under on-first-retry, because the run's final status is green; if flake investigation matters more than storage cost, retain-on-failure records on every failure including ones later retried away.

• -

  if: failure() skips the upload step on a run that was cancelled rather than failed; add if: failure() || cancelled() when artifacts from a cancelled run are also worth keeping.

• -

  Restricting the install to one browser (chromium) breaks a suite that runs cross-browser projects in playwright.config.* - check the config's projects list before narrowing the install command.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to run this audit and open the fix as a reviewable PR.

Audit this repository's Playwright configuration and CI workflow for unconditional
artifact capture and fix what you find.

1. Read playwright.config.* and check the trace, video, and screenshot options. If any is
   set to 'on', propose changing trace to 'on-first-retry' (or 'retain-on-failure' if the
   repo does not configure retries) and video to 'retain-on-failure'.
2. Read the workflow file that runs the suite. For every actions/upload-artifact step that
   uploads a Playwright report or test-results directory, add if: failure() unless it
   already has an equivalent condition.
3. Check the playwright install step. If playwright.config.* defines projects for only one
   browser, propose narrowing npx playwright install --with-deps to name that browser
   explicitly; if multiple browser projects are configured, leave the install as is.
4. Read the Playwright trace viewer, test configuration, and CI docs linked on this page
   before editing.
5. Show the full diff and open a pull request; do not apply changes blindly. In the PR
   body, state how to verify: force a failing test and confirm a trace/video is still
   produced and uploaded, then confirm a passing run skips the upload steps.