Repository navigation
Tag builds restore an empty cargo cache #2038
Description
release.yml sets Swatinem/rust-cache save-if to false, with key release-${target}. The comment (#1396) is that a tag's cache is readable by nothing later, and each release spent about 1.6 GB of the 10 GB store, evicting the entries CI restores. On 5.3.1 every restore finished in about two seconds, which is a miss. The next tag compiles from scratch.
The part a cache can save is the dependency compile, not the fat link. On Linux the cold default build was 25 minutes and the warm graph build was 18, so the dependencies are about 7 minutes there. On the Mac the only number we have is the cold 87 minute build, so the miss may be a larger share of that.
Save a dist cache without putting it in the same 10 GB LRU as the CI keys. If GitHub's one cache budget cannot hold both, leave the miss in place and say so here. Do not turn save-if back on against the CI keys.
Done when a second tag either restores a dist cache and the cold portion shrinks by the measured dependency time, or this issue records that the 10 GB budget cannot hold it without slowing CI.
Activity
cargopete commentedon Oct 16, 2026
Recording the outcome this issue allows for: the 10 GB budget cannot hold a
distcache without slowing CI.On 2026-10-16 main's CI caches alone total 10.79 GB across 9 entries (check-no-count 2.86 GB, pg-parity 2.08, graph-facade 2.08, build-release 1.53, check-default 1.22, fleet 0.70, fuzz-smoke 3 × 0.09), already over the budget, and the test-shard caches no longer appear, so they are being evicted now. Since #2068 a tag runs seven (target, variant) jobs; a saved
distcache per job would be roughly 1.5 to 2 GB each, more than the whole budget again, and every one would push out an entry CI restores on the next PR. GitHub has one cache store per repository, so there is no separate budget to put it in.save-if: falsestays. With the builds parallel the dependency compile is paid once per job concurrently rather than three times in series, which is the saving this issue was after.