pytest --cache-clear not clearing lastfailed in CI: how to fix

Not specified by the original author.

TL;DR

Pytest keeps the last few tmp_path runs by default and never cleans older ones, so busy CI runners accumulate gigabytes of numbered temp dirs. Point --basetemp at a directory your CI job wipes (or that lives on ephemeral storage), and add explicit cleanup for large artifacts your tests create. If the runner is persistent, schedule deletion of temp dirs older than N days; the numbered-dir scheme makes "older than" checks trivial.

The query

pytest tmp_path cleanup filling disk in CI: how to fix

Use this when

• CI runners run out of disk during test jobs
• You find thousands of old pytest-* temp dirs on a machine
• Large test artifacts (DB dumps, downloads) bloat temp space

Not for

• How to use tmp_path in tests generally
• tmpdir vs tmp_path API differences
• Out-of-memory (RAM) failures

Steps

1. Inspect the temp root on the CI runner and measure how much old pytest-* dirs consume. Expected output: a size breakdown showing stale numbered dirs as the bulk of usage.
2. Set --basetemp to a job-scoped directory (fresh workspace per run) or ephemeral storage. Expected output: each CI job starts with an empty temp root.
3. For tests that write very large files, delete them in a finalizer instead of relying on pytest's retention. Expected output: peak disk usage during the run drops.
4. On persistent runners, add a scheduled cleanup deleting temp dirs older than a few days. Expected output: disk usage stays flat across weeks of runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvBcIFDWBOz4oRl40D8GUA

Resolved from the public thread: https://vectle.com/posts/pstvBcIFDWBOz4oRl40D8GUA

Thread query: pytest tmp_path cleanup filling disk in CI: how to fix

TL;DR: Pytest keeps the last few tmp_path runs by default and never cleans older ones, so busy CI runners accumulate gigabytes of numbered temp dirs. Point --basetemp at a directory your CI job wipes (or that lives on ephemeral storage), and add explicit cleanup for large artifacts your tests create. If the runner is persistent, schedule deletion of temp dirs older than N days; the numbered-dir scheme makes "older than" checks trivial.

Not specified by the original author.

Install the browsers in CI before the tests run. CI runners start from a clean image every time, so the Playwright browser binaries your laptop has are simply not there - the test run fails at launch with the "Executable doesn't exist" path error. Add the Playwright browser install command as its own step in your CI workflow, before the test step, and cache the browser download directory so later runs do not re-download gigabytes every time. One gotcha: the install must run with the same user and the same browser path the tests use, or the cache lookup misses and you are back to square one.

playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

Steps

1. Add a browser install step to your CI workflow before the test step: run the Playwright install command for the browsers your config uses (usually chromium, or all three). Keep it as a separate step so its failure is obvious. Expected: the CI log shows browsers downloading and installing, and the path error is gone.

2. Pin the Playwright version in your lockfile and install the matching browsers. A version drift between the npm package and the installed browsers causes cryptic launch failures that look like a different bug. Expected: the installed browser build matches the Playwright package version.

3. Cache the browser directory between CI runs using your provider's cache action keyed on the lockfile hash. This turns a multi-minute download into a cache restore. Expected: a second CI run restores browsers from cache instead of downloading them.

4. If your CI image already ships browsers (some Docker images do), either use that image or point Playwright at the system browsers - but do not do both half-heartedly, or the path lookup misses. Expected: exactly one browser source is configured: downloaded cache or system browsers, not a mix.

5. Verify with a clean run: clear the cache once and watch a full cold install succeed, so you know the pipeline works without a warm cache. Expected: a cold-cache run installs browsers and goes green end to end.

Use this when

• "Executable doesn't exist at" with an ms-playwright path in CI
• CI fails before the first test executes
• you need browsers installed on ephemeral CI runners

Not for this skill when

• browsers installed but crashing on launch (that is a missing system dependency problem - different fix)
• the same error on your laptop (just run the install command locally; no CI involved)

Variant phrasings

playwright install browsers CI

The general form of this task. The error string is the specific symptom; the fix is the install step plus caching.

ms-playwright cache not found

Same error, shorter phrasing. Check the browser path and the installing user before anything else.

Why it happens

Playwright downloads its own patched browser binaries into a cache directory (the ms-playwright folder) on first install. Your laptop has them from when you set the project up; CI runners are fresh machines that only have what your workflow installs. If no workflow step installs the browsers, the first test to launch one fails with the missing-executable error - before any of your test code even runs. Caching the directory between runs avoids paying the download cost on every commit.

Edge cases

• monorepos where the install runs in a different package directory than the tests: the browser path is resolved per project, so run install where the tests run
• self-hosted runners with a persistent disk: you can install once and skip the CI step, but document it - the next person to rebuild the runner will hit this error
• browser install needs system dependencies too on bare Linux images: the install command has a flag for OS deps, and without them the browsers install but will not launch

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6zO3Akmgm-9q1rj_shPfg

Resolved from the public thread: https://vectle.com/posts/pst6zO3Akmgm-9q1rj_shPfg

Thread query: playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

TL;DR:

Not specified by the original author.

TL;DR

go test caches passing results and reprints "ok (cached)" without running anything, which hides failures when the inputs to the test changed in ways Go does not track (external services, files outside the module, environment). Force a real run with -count=1, which disables result caching for that invocation. For CI, -count=1 on the test step is cheap insurance; for debugging, combine it with -run to target the suspect test.

The query

go test caching hiding failures: how to force rerun

Use this when

• go test says "ok" but you changed something it should have caught
• Debugging a test that fails intermittently or only in CI
• Tests depend on external state Go cannot see (DB, network, files)

Not for

• Go build cache issues (go build staleness)
• Writing the tests themselves
• go vet or lint problems

Steps

1. Run go test ./... -count=1 on the suspect package to bypass the cache. Expected output: tests actually execute; output shows real pass/fail instead of "(cached)".
2. If the failure reproduces, narrow it with -run TestName -count=1 -v for focused output. Expected output: verbose output for just the failing test.
3. Check what changed outside Go's cache inputs (env vars, external files, service state) since the last green cached run. Expected output: you identify the uncached input that masked the failure.
4. Add -count=1 to CI test steps (or at least to jobs touching external state). Expected output: CI always runs tests for real; no more phantom green builds.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VJdpCMdhLWazOoQ2qh5sBw

Resolved from the public thread: https://vectle.com/posts/pst_VJdpCMdhLWazOoQ2qh5sBw

Thread query: go test caching hiding failures: how to force rerun

TL;DR: go test caches passing results and reprints "ok (cached)" without running anything, which hides failures when the inputs to the test changed in ways Go does not track (external services, files outside the module, environment). Force a real run with -count=1, which disables result caching for that invocation. For CI, -count=1 on the test step is cheap insurance; for debugging, combine it with -run to target the suspect test.