Save the cargo cache from main only
Every Swatinem/rust-cache step gets save-if: ${{ github.ref == 'refs/heads/main' }}, so pull requests and tag builds restore the cache but no longer save entries of their own.
Why. GitHub caps a repository's cache at 10 GB and evicts least-recently-used. This repo sits at the cap (99 entries). Every PR run saves an entry scoped to that PR, which only a re-run of the same PR can restore, yet each one pushes main's entries, the ones every PR restores from, towards eviction. On basecamp-sdk the effect is already measurable: Rust stable found no cache on 4 of its last 8 runs, including a push to main, and took 341 s instead of 210 s. Here the last 8 Rust jobs all restored something, but the churn is identical, and this keeps main's entries in place.
What changes for a pull request. Restore is unchanged: PRs already read main's entries and could never write to them. What goes is the Post Cache cargo step, about 8 s of cleanup and upload at the end of each Rust job. Tag builds in release-rust.yml keep restoring from main and stop saving tag-scoped entries that nothing re-reads; a workflow_dispatch rehearsal from main still saves.
Risk. None: this changes when entries are written, not what is restored. Rollback is reverting this commit.
Numbers and rationale: build cache assessment, §4.3 and §5 Option A.
Summary by cubic
Stops pull requests and tag builds from saving their own cargo cache entries, so main's entries survive longer under GitHub's 10 GB eviction cap. Restore behavior is unchanged: PRs and tags still read main's cache, they just no longer write their own.
- Adds
save-if: ${{ github.ref == 'refs/heads/main' }}to everySwatinem/rust-cachestep intest.ymlandrelease-rust.yml. - PR-scoped saves were evicting main's entries; on basecamp-sdk the Rust job missed the cache on 4 of its last 8 runs (341 s instead of 210 s).
- PR jobs lose the ~8 s post-cache save step; a
workflow_dispatchrehearsal from main still saves. - Rollback is reverting this commit; no migration needed.