Repository navigation
ci(cache): rust-cache saves on pull requests — 13.4 GB of unreachable PR-ref caches over the 10 GB limit; add save-if and guard it #1216
Description
Failure
running-process's Actions cache is over GitHub's 10 GB repository limit, and nearly all of it is unreachable: 32 entries, 13.36 GB, all on refs/pull/1215/merge. A cache saved on a PR's merge ref can only be restored by later runs of that same PR, yet it counts against the limit and evicts main's entries, so every other ref starts cold.
Every entry is Swatinem/rust-cache (v0-rust-*). The largest are 0.9–1.85 GB per job: v0-rust-windows-x86-* 1.85 GB, v0-rust-windows-arm-* 1.83 GB, v0-rust-output-shutd* 1.36 GB (6 entries), v0-rust-linux-x86-mu* 1.22 GB, and so on.
Mechanism
Swatinem/rust-cache@v2 saves on every event unless save-if is set. None of the ~12 uses in .github/workflows/ set it: _build.yml:93, ci-all-features.yml:105, ci-linux.yml:92, ci-output-shutdown.yml:56, ci-preflight-rust.yml:75,101,131, ci-preflight.yml:101, coverage.yml:69, independent-spawn.yml:52,117, linux-x86-build.yml:58, auto-release.yml:542, and the other per-platform build workflows. Many jobs also use a distinct key:, so one PR writes one ~1–2 GB entry per job.
Proposal
Fix
- Add
save-if: ${{ github.ref == 'refs/heads/main' }}(orgithub.event_name != 'pull_request') to everySwatinem/rust-cachestep. PR runs keep restoring frommain's entries. - Where jobs build the same graph on the same OS, share a
keyorshared-keysomainkeeps one entry per OS × graph instead of one per job.
Catch it so it does not recur
- A lint-lane check (a small script under
ci/) that fails when anySwatinem/rust-cache(oractions/cachesave) step can save onpull_requestwithout an explicit, commented exemption. RED on today's workflows. - Optionally, a scheduled check that reports PR-ref cache bytes and fails above a small allowance.
Acceptance criteria
- After a PR run, no new
refs/pull/*v0-rust-*entries exist;mainholds one entry per OS × graph; the repository total stays well under 10 GB. - PR builds still restore warm from
main(record hit rate and wall time before/after). - The check is RED before the change and GREEN after.
Related
- Part of the cross-repo cache-footprint meta (linked from the parent issue). This is independent of fix(cache): never save durable caches from pull-request runs by default — they are unreachable and fill consumers' 10 GB budget (zccache 11.75 GB, kernal-api ~23 GB offered) forge-ci/setup-soldr#527, which is the same bug in setup-soldr's own save paths.
Activity
ci(cache): gate every cache save to main and guard it (#1216)
test(lint): expect the cache-save guard in the lint command sequence (#…
ci(cache): gate every cache save to main and guard it (#1216)
test(lint): expect the cache-save guard in the lint command sequence (#…
zackees commentedon Sep 27, 2026
Reopening: the prior main-only save gate prevented PR-ref cache growth but did not cap main-ref writes. Scheduled All-Features run 36319601595 (2026-09-27) saved three distinct
v0-rust-*-all-featuresentries onrefs/heads/main: macOS ARM ID 8176285621 (649,556,636 B), Windows x86 ID 8176434675 (850,009,549 B), macOS x86 ID 8176621221 (645,299,171 B), total 2,144,865,356 B. The Windows job failed one flaky TUI ANSI test, butcache-on-failure:truestill saved its 850 MB archive. Afterward the usage endpoint and paginated cache list both settle at 11,027,243,685 B (list count differs from usage count; byte totals match), above the 10 GiB repository cap. Currentci-all-features.ymlalready has the #1216 main-onlysave-ifgate; schedules haverefs/heads/main, so this is allowed under the existing ownership rule. The gap is no live total-budget guard and no retention for this optional dedicated family. Follow-up will make that lane restore-only, retire only the exact three all-features main families through a reviewed workflow, and add RED/GREEN budget/ownership tests. No cache has been manually deleted.zackees commentedon Sep 27, 2026
Closure evidence (2026-09-27)
The cache overage is resolved with reviewed producer/retention policy and main-run budget enforcement; no cache was manually deleted.
8181253810, 2,105,526,302 B, Windows ARM shared preflight target cache.8180667758, 944,115,359 B, coverage target cache.Total removed: 3,049,641,661 B. Their registry-only replacements remain: ID
8182796929(86,534,903 B) and ID8182505889(99,540,621 B). The final guard passed with endpoint and list equal at 8,596,607,472 B (limit 9,500,000,000).Known validation exception: the optional all-features Windows run failed its pre-existing
daemon_tui_repaint_test::raw_ansi_bytes_flow_through_pty_to_ring_buffertest (2,554/2,555 passed after retries); this was documented and did not affect the regular platform matrix or cache policy.