ci(release): dependency-pruned build cache + arm64 timeout headroom - #762
Conversation
The arm64 recollapse in #757 cut timeout-minutes 90->60 on the assumption the single combined cross build would be faster. A post-merge dry-run (run 29375276363) showed the cold-cache build runs ~65m and hit the 60m cap, cancelling the job and skipping initramfs/release/stage. The recollapse saves link time, not the dominant aws-lc-sys musl compile, so restore the 90m headroom the split had. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
…save) The two linux release builds cached the whole target/ (the largest in the repo) via raw actions/cache into the 10 GB per-repo LRU shared with every PR lane, so entries were evicted fast and release builds kept starting cold — the arm64 dry-run ran ~65m from cold. Swap to Swatinem/rust-cache, which prunes target/ to the dependency artifacts (the dominant aws-lc-sys compile) so the entry is small enough to survive; save-if main-only stops branch and dry-run dispatches from churning the budget. cross reads ~/.cargo and writes target/ on the host, so rust-cache caches the arm64 build the same as a native one. The 90m arm64 cap stays: a cache miss is still cold. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two related changes to the release build's critical path (the arm64 job — it runs parallel to amd64/macOS, which finish far sooner, so it sets release wall clock).
1.
perf: dependency-pruned build cache (rust-cache)Both linux release builds already cached
target/— but via rawactions/cacheof the entire target dir, which the comment on the amd64 job calls out as the largest target dir in the repo (multi-GB). Cached whole into the 10 GB per-repo LRU it shares with every PR lane, the entries get evicted fast, so release builds keep starting cold — the post-PR9 arm64 dry-run (run 29375276363) ran ~65 min from cold, while warm pre-PR9 runs were 19–42 min. The 3× swing was cache hit-vs-evicted, not job structure.Swap the two linux builds to
Swatinem/rust-cache@v2(already used insetup-rust):target/to just the dependency artifacts (the costlyaws-lc-sys/crypto compiles) — the entry is small enough to survive the LRU instead of being evicted.save-if: github.ref == 'refs/heads/main'— real releases (dispatch/nightly.ymlcall, both onmain) warm the cache; branch/dry_rundispatches restore read-only so they stop churning the budget and evicting main's warm cache.crossreads~/.cargoand writestarget/on the host, so rust-cache caches the arm64 build the same as a native one.Expected effect: typical arm64 build drops from cold ~65 min toward warm ~15–20 min. macOS (self-hosted mini, persistent local
target/) andbuild-libkrun(cached viavendor/libkrun.lock, #694) are deliberately left untouched.2.
ci: restore arm64 timeout 60 → 90PR9 (#757) recollapsed the arm64 build to one
cross buildand cut the timeout 90→60 on the assumption it'd be faster. The dry-run proved a cold build exceeds 60 min → cancelled → skippedinitramfs/release/stage-installer. The cache above makes the typical run fast, but a cache miss (first build,Cargo.lockchange, LRU eviction) is still cold, so the cap must still clear the cold case — 90 stays.Validation
actionlint clean (only the pre-existing shellcheck infos in untouched scripts). Full proof is a
dry_run: truerelease dispatch on this branch: first run cold (populates the cache frommainonly — so validate warmth via a second dispatch, or note the first dry-run on a branch won't save). The correctness net is cargo's own fingerprinting — a stale cache triggers a rebuild, never a bad binary.🤖 Generated with Claude Code