Playwright Trace Recording vs CI Disk Quota: Unresolved Cleanup Timing

Question

Trace Recording in CI
Playwright’s trace feature captures page actions, network traffic, and screenshots. In local development, developers often enable trace: 'on' to collect traces for every test, which works because the local file system has ample space and no CI restrictions. In continuous‑integration (CI) environments, however, enabling trace for all tests can trigger errors such as Failed to record trace: Disk quota exceeded or failures due to missing GPU support for certain browsers.
When trace: 'on-first-retry' is used, Playwright writes trace files to a temporary directory that is cleaned up after the test run. The exact moment of this cleanup—immediately after the first retry or only after all retries have completed—is not clearly documented, leading to uncertainty about whether trace artifacts survive long enough for debugging or are prematurely deleted.
Additionally, the automatic upload of trace files to Playwright Inspector appears to require an explicit flag or environment variable, yet the documentation does not specify if this upload occurs consistently across Playwright versions.
Given these ambiguities, how does Playwright determine when to delete trace files after retries in a CI pipeline? Does the cleanup happen after the first retry or after all retries have finished? Under what conditions, if any, are trace files automatically uploaded to Playwright Inspector in a CI environment?

Tasadduq Burney · Answer

Answer
In a CI job that uses playwright test, trace files created with trace: 'on-first-retry' are written to the runner’s test-results directory and are only removed when the Playwright test runner process finishes. That means the files survive all retries – they are not deleted immediately after the first retry. The trace artifacts are not automatically uploaded to Playwright Inspector; the Inspector is a local viewer that expects a local trace file. If you want to make traces available in a CI pipeline you must explicitly archive or upload the test-results folder (e.g., with GitHub Actions actions/upload-artifact or a similar consumer).

Key Points

trace: 'on-first-retry' starts recording only when a test fails and is retried for the first time.
The Playwright test runner keeps the trace file open in the test-results directory until the runner terminates.
Cleanup happens after the runner exits, i.e., after all retries have completed.
No built‑in flag or environment variable triggers an automatic upload to Playwright Inspector in a CI environment.

Practical Steps for CI

Configure the test in playwright.config.ts:
export default {
  retries: 2,
  use: {
    trace: 'on-first-retry',
  },
};

Run the tests in your CI job. For example, in GitHub Actions:
steps:
  - uses: actions/checkout@v4
  - name: Install dependencies
    run: npm ci
  - name: Run Playwright tests
    run: npx playwright test
  - name: Upload traces
    uses: actions/upload-artifact@v4
    with:
      name: playwright-traces
      path: test-results/**

If your CI provider cleans the workspace only after the job ends, the traces will remain until that point and can be downloaded as artifacts.

Diagnostic Question
Could you confirm which CI platform you’re using (GitHub Actions, GitLab CI, Azure Pipelines, etc.) and whether you already archive the test-results folder? That will help tailor the upload instructions to your environment.

Playwright Trace Recording vs CI Disk Quota: Unresolved Cleanup Timing

Trace Recording in CI

1 answer

Answer

Key Points

Practical Steps for CI

Diagnostic Question

Your perspective belongs here.

0 question comments