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.

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

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

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