ci: bound the cargo cache to master, and stop the npm cache from crowding it out

[PathGao]

Follow-up to #572, which added the cargo cache and named two things it could not settle. Both turned out to matter, and there is now a measurement.

The repository was already over its cache limit

active:  13.22 GB / 117 entries        limit: 10 GB

  npm    113 entries   8.76 GB    across 50 refs — mostly closed PRs
  rust     4 entries   4.45 GB    written by one run of #572

Over the limit GitHub evicts least-recently-used, and the cargo caches are the largest entries here — so they are what disappears. Two pull requests in flight overflow the budget on their own.

#572 saved nothing, and that is measured, not predicted. #573's Linux job ran in 12m12s against the 12m14s baseline #572 was written from. A branch can only restore caches written on itself or its base, test_build.yml had no push trigger, so every cache it wrote was scoped to a pull request branch that no other branch could read.

Four changes

save-if: github.ref == 'refs/heads/master' in test.yml and test_build.yml. Pull requests restore and save nothing, so the total is one set rather than one set per branch in flight.

test_build.yml now runs on push to master. This is not a separate optimisation — it is what save-if requires. Restricting writes to master means master has to write, and it was not running there at all. Same paths-ignore, and cancel-in-progress restricted to pull requests for the reason test.yml already gives: cancelling a master run because a second merge landed would discard the compile that was going to fill the cache.

build.yml loses its cache. Four more entries is another ~4.5 GB, spent on the least valuable minutes here — workflow_dispatch-only, roughly weekly, and nobody waits on a release build the way they wait on a pull request check. Its jobs already finish in 12–16 minutes. The comment names it as the first place to add one back if the limit stops binding.

cache: npm is removed. It was the larger consumer and nothing can bound it: caches are scoped by ref, so setup-node writes one per branch per platform with no save-if equivalent. Measured on runs that hit it, npm ci took 6s on Linux, 9s on macOS, 15–17s on Windows — and it caches ~/.npm, not node_modules, so npm ci still runs and still links all 190 packages. The saving is the registry fetch alone, from runners that sit close to the registry. Seconds per job, for the budget that makes an eight-minute saving possible.

Stale caches from closed pull requests were also deleted by hand: 117 entries / 13.22 GB → 31 / 3.15 GB.

Cost, stated plainly

One extra three-platform run per merge to master. On a public repository the minutes are free; what it spends is macOS runner availability, which test_build.yml's own comment notes is the scarce pool. Against that, every pull request opened afterwards starts warm, and pull requests are pushed to far more often than master is merged into. Only the first master run is a full cold compile.

Plus 10–20 seconds per job for the npm fetch.

Tests

scripts/ciCacheBudget.test.ts holds both halves of the budget: every rust-cache use restricts its save to master, and no workflow re-enables the npm cache. Mutation-checked — removing save-if fails the first and not the second; re-adding cache: npm fails the second and not the first.

Neither is a law of nature, and the comments say so. The point is that the next change to either has to re-do the measurement rather than rediscover the ceiling.

npm test	965 pass
npm run check	675 files, 0 errors
YAML re-parse	triggers confirmed on all changed workflows

What still is not verified, and how to settle it

The first master run after this merges is a cold compile that writes the caches. Then open a trivial pull request and compare its Linux job against 12m14s.

If it has not moved meaningfully, the honest response is to revert the caching entirely rather than keep it as decoration — it costs budget, a new trigger, and four blocks of comment. #572 is already one example of caching that looked right and saved nothing.

🤖 Generated with Claude Code

[PathGao]

Measured. #575 is the first pull request that could read the caches this seeded, so the self-revert clause above can be settled.

It works. Wall-clock time for a pull request is roughly halved.

Same workflow configuration in both columns — the only difference is whether master had a cache to restore.

job	cold (master seeding, this PR)	warm (#575)
build-test linux	12m49s	7m08s	−44%
build-test windows	16m03s	8m16s	−48%
build-test macos	17m30s	8m51s	−49%
test	~4m50s	2m43s	−44%

Wall clock is set by the slowest job, so what a contributor actually waits for went 17m30s → 8m51s.

Step level, on Linux:

cache rust dependencies    26s     ← the cost
run cargo test           151s →  15s    −90%
Build app                477s → 291s    −39%
Post cache rust deps       0s     ← save-if working: the PR wrote nothing

Post cache rust dependencies: 0s on all three platforms is the part worth noting separately: pull requests restore and save nothing, which is what keeps the total at one set. Cache usage is 4.45 GB against the 10 GB limit, down from 13.22 GB before this.

The cargo test and Build app figures also answer the open question about extrapolating between profiles. The debug-profile step fell 90% and the release-profile step 39% — the ratio does not carry across, which is why this was measured rather than predicted.

So: no revert. The extra three-platform run per merge is buying about nine minutes off every pull request that follows it.