ci(test): host-persistent target dir; fast fmt gate; drop dead rust-cache #176

2026-07-13T20:53:54Z

funman300 commented

2026-07-13 20:53:54 +00:00

Fixes the repo-side causes of the ~40-minute test runs (diagnosed from runs 597/600/601 logs).

Root cause found

The Gitea actions cache on this instance stores but never restores: run 597 tarred and uploaded a 1.85 GB cache ('Cache saved successfully'), and the very next run — same exact key, same day — logged 'No cache found'. This holds for every run checked, including master→master. Every CI run has been a full cold Bevy build (~9.5 min clippy + ~27 min test) plus ~4 wasted minutes saving a cache nobody can read.

Changes

CARGO_TARGET_DIR → persistent path on the runner host. rust-host is a host executor, so the filesystem carries over between runs (that's why rustup installs in 1 s). Warm builds without the cache API. A prune step resets the dir past 40 GiB. Concurrent runs are safe — cargo serialises on the target-dir lock.
Drop Swatinem/rust-cache — pure overhead until the server-side cache is fixed.
fmt as its own seconds-long job gating test via needs, so a rustfmt slip fails in under a minute instead of after a full build (run 600).
CARGO_BUILD_JOBS=2 and line-tables-only kept — they guard against the documented linker OOMs, and with warm builds their cost is negligible.

Expectations

This PR's own run is still cold (it populates the new target dir): ~35–40 min.
Runs after that should be a few minutes.
First run adds up to ~20 GB on the runner's disk (capped at 40 GiB by the prune step) — worth a quick df -h on the runner host.

Still server-side (not fixable from the repo)

The broken cache restore also slows web-e2e (docker executor — no persistent filesystem, genuinely needs the cache server). Also, Gitea is accumulating ~2 GB of dead cache per historical run; the instance's actions-cache storage likely wants a look/purge. Happy to dig in if you point me at the runner host.

🤖 Generated with Claude Code

Fixes the repo-side causes of the ~40-minute test runs (diagnosed from runs 597/600/601 logs). ## Root cause found The Gitea actions cache on this instance **stores but never restores**: run 597 tarred and uploaded a 1.85 GB cache ('Cache saved successfully'), and the very next run — same exact key, same day — logged 'No cache found'. This holds for every run checked, including master→master. Every CI run has been a full cold Bevy build (~9.5 min clippy + ~27 min test) plus ~4 wasted minutes saving a cache nobody can read. ## Changes - **`CARGO_TARGET_DIR` → persistent path on the runner host.** `rust-host` is a host executor, so the filesystem carries over between runs (that's why rustup installs in 1 s). Warm builds without the cache API. A prune step resets the dir past 40 GiB. Concurrent runs are safe — cargo serialises on the target-dir lock. - **Drop `Swatinem/rust-cache`** — pure overhead until the server-side cache is fixed. - **`fmt` as its own seconds-long job** gating `test` via `needs`, so a rustfmt slip fails in under a minute instead of after a full build (run 600). - `CARGO_BUILD_JOBS=2` and `line-tables-only` kept — they guard against the documented linker OOMs, and with warm builds their cost is negligible. ## Expectations - This PR's own run is still **cold** (it populates the new target dir): ~35–40 min. - Runs after that should be **a few minutes**. - First run adds up to ~20 GB on the runner's disk (capped at 40 GiB by the prune step) — worth a quick `df -h` on the runner host. ## Still server-side (not fixable from the repo) The broken cache restore also slows `web-e2e` (docker executor — no persistent filesystem, genuinely needs the cache server). Also, Gitea is accumulating ~2 GB of dead cache per historical run; the instance's actions-cache storage likely wants a look/purge. Happy to dig in if you point me at the runner host. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

funman300 added 1 commit 2026-07-13 20:53:54 +00:00

ci(test): host-persistent target dir; fast fmt gate; drop dead rust-cache

Test / fmt (pull_request) Successful in 5s

Details

Test / test (pull_request) Successful in 33m27s

Details

d593b61af8

The Gitea actions cache on this instance stores caches (1.85 GB saves
confirmed in run 597) but never restores them — every run back through
run 584+ logs 'No cache found' even for exact keys saved an hour
earlier, including master-to-master. Every CI run has therefore been a
full cold build (~37 min), plus ~4 min tarring a cache nobody reads.

- Point CARGO_TARGET_DIR at a persistent path on the rust-host runner
  (host executor — filesystem carries over between runs), with a 40 GiB
  prune guard. Warm runs drop to minutes without touching the broken
  cache API.
- Drop Swatinem/rust-cache (pure overhead until the server is fixed).
- Split cargo fmt --check into a seconds-long fmt job gating the heavy
  test job, so a formatting slip can't burn a 35-minute build again
  (run 600).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

funman300 merged commit 81ac4a5383 into master

2026-07-13 22:14:40 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: funman300/Ferrous-Solitaire#176