Repository navigation
Run CI on dev pushes and save the Rust cache only there so PRs can finally restore it - #873
Merged
Merged
Conversation
…nally restore it Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: WaylandYang <145302500+WaylandYang@users.noreply.github.com>
This was referenced Sep 23, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The Rust build cache in this repository has never been restored, not once. Evidence from today's 12
backendruns:Teststep compiles 314 crates, 9 of them ours. The other ~305 dependencies are built from scratch every run (Clippy ~140s, Test compile ~180s,迁移测试库~70s,sqlx-cliinstall ~78s).Swatinem/rust-cacherestore takes 0–2s and logsNo cache foundon every run, including second runs of the same PR.actions/cache/usage: 17 entries, 10.7 GB against the 10 GB quota, all created today, all underrefs/pull/N/merge, and every entry'slast_accessed_atequals itscreated_at.Three things combine:
pushonly formain. Nothing ever runs ondev, so there is no cache on the base branch that PRs could read. GitHub lets a PR read caches from its own ref, its base branch and the default branch only, so PRs never see what other PRs saved.backend~1 GB +migrations~0.9 GB). Five or six PRs fill the 10 GB quota and LRU eviction starts.What
on.push.branches: [main, dev]. Each merge intodevruns CI and saves a cache underrefs/heads/dev, which every PR targetingdevcan restore. This also closes the gap themigrationsjob header comment describes: the merged state ofdevnow gets a CI run.save-if: ${{ github.event_name == 'push' }}on bothrust-cachesteps. PRs restore only; onlydev/mainpush runs write. The cache footprint becomes ~2 GB total instead of thrashing at the quota.~/.cargo/binis part of that cache, sosqlx-clistops being reinstalled per run too.Workflow-level
permissions: contents: readuntouched.What to expect
This PR's own run cannot show the speedup: no
devcache exists yet. The first push todevafter merging (this merge itself) saves it; the next PR run should restore ~1 GB in ~20–30s and then compile only the workspace crates and link the test binaries. Rough expectation: Clippy 140s → ~40s, Test compile 180s → 60–80s,迁移测试库70s → ~15s,装 sqlx-cli78s → seconds. Those are estimates, not measurements; I'll verify on thedevpush run (cache saved) and the next PR run (cache restored).🤖 Generated with Claude Code