Cargo Test Workspace No Space Left On Device In GitHub Actions

When cargo test --workspace fills a GitHub-hosted runner, the fix is rarely a blind rm -rf target. Measure which workspace members, profiles, Docker testcontainers, Trunk or wasm builds, and incremental artifacts create the peak disk footprint, then split the job around those peaks.

Rust CI disk triage

Find the peak `target/` and Docker footprint before changing the workflow.

This read-only command reports runner space, Rust build output, dependency cache, Docker usage, and the largest target directories. It does not delete build artifacts.

df -h; du -sh target ~/.cargo/registry ~/.cargo/git /tmp 2>/dev/null || true; find target -mindepth 1 -maxdepth 3 -type d -exec du -sh {} + 2>/dev/null | sort -hr | head -40; docker system df -v 2>/dev/null || true

Request $29 CI triage Open backup request Runner guide

Copy-ready issue reply

Use this before deciding whether to shard, clean, or cache differently.

Paste this into a Rust CI issue to capture evidence without changing the workflow yet.

Before splitting or deleting caches, capture the peak disk buckets from the failing Rust job:

df -h
du -sh target ~/.cargo/registry ~/.cargo/git /tmp 2>/dev/null || true
find target -mindepth 1 -maxdepth 3 -type d -exec du -sh {} + 2>/dev/null | sort -hr | head -40
docker system df -v 2>/dev/null || true

Then split by peak producer, not by test count:
- testcontainers / Docker-backed tests in their own job
- Trunk, wasm, napi, tauri, or GUI example builds in their own job
- host-only unit tests in a job that excludes heavy examples
- print disk usage before and after each shard so a dependency bump cannot silently push the runner over the edge

Request $29 triage

Why Cargo Workspaces Fill Runners

One command compiles too much: cargo test --workspace can compile crates with no tests if they are workspace members or dependencies of examples.
Feature and profile fanout: multiple feature sets, build scripts, proc macros, and release-like profiles duplicate build output.
Heavy examples: Tauri, GTK/WebKit, wasm, napi, Trunk, or browser examples often dominate the disk even when they are not part of the failing test.
Docker-backed tests: testcontainers images, layers, volumes, and logs add a separate peak outside target/.
Incremental artifacts: useful locally, but often expensive in short-lived CI jobs when many crates build at once.

Safe Split Order

Measure target/, Cargo registry/git cache, Docker, and /tmp before the cleanup step.
Create a Docker/testcontainers shard first if Docker contributes meaningful space.
Create a Trunk/wasm/napi/tauri shard for frontend or GUI-adjacent crates.
Run host-only unit tests with a denylist for heavy examples rather than an allowlist that misses inline tests.
Only clean target/ between shards if later steps do not need the compiled outputs.
Keep disk telemetry in every shard so the next dependency bump is caught early.

Shortest paid path

Want the first safe shard and cleanup policy?