chore(ci): inline dtolnay/rust-toolchain, SHA-pin every other third-party action - #8684
Closed
jdalton wants to merge 1 commit into
Closed
chore(ci): inline dtolnay/rust-toolchain, SHA-pin every other third-party action#8684jdalton wants to merge 1 commit into
jdalton wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (18)
🚧 Files skipped from review as they are similar to previous changes (10)
Included review availability: Your plan provides up to 8 included reviews per hour; 4 remain after this review. 📝 WalkthroughWalkthroughChangesThe pull request pins GitHub Actions to immutable commit SHAs across CI, release, packaging, deployment, and analysis workflows. Rust workflows install CI workflow hardening
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The workflow updates are merge-ready after normal checks and review; no actionable merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…arty action dtolnay/rust-toolchain appeared 45 times across 23 workflow files, and every call site passed the same toolchain that rust-toolchain.toml at the repo root already pins - installing it is one rustup command, so there is no reason to depend on a third-party action for it. Replaced every occurrence with an inline rustup toolchain install step, translating each site's components/targets inputs into matching flags. Every other action reference still pinned to a mutable tag now pins the commit SHA that tag currently resolves to, with the tag kept as a trailing comment. Found and fixed a real bug along the way: taiki-e/install-action@v3 does not exist upstream (latest is v2.86.6), so coverage.yml's cargo-llvm-cov install had failed with startup_failure on every scheduled run for weeks. Also caught and corrected two annotated-tag SHAs (Swatinem/rust-cache, mozilla-actions/sccache-action) that had resolved to the tag object instead of the commit it points to - verified each pin resolves to a real commit via the GitHub API before landing.
jdalton
force-pushed
the
chore/pin-and-inline-actions
branch
from
August 24, 2026 04:02
9911c25 to
0ebb885
Compare
proggeramlug
added a commit
that referenced
this pull request
Aug 24, 2026
…CI hardening (#8696) Lands #8687, #8686 and #8684. #8687 (closes #8679) replaces the post-RS4GC instruction-budget hard refusal with a typed spill-retry: an already-lowered LlFunction switches from native statepoint roots to a complete precise shadow frame and the unit is rebuilt at the originally requested optimization level. This is the durable handling for the estimator misses #8678 could only make more accurate. Retry termination is guaranteed rather than argued. `request_shadow_frame_spill()` latches on `force_shadow_frame` and returns false if already set; `apply_budget_spill_retry` records only the functions where it returned true, and any violation not recorded becomes a hard error naming it. A function therefore cannot be retried twice. #8686 builds the gap suite's fast-mode archives once in a dedicated `gap-suite-build` job and shares them across the six shards. The skipped-vs-failed distinction is handled explicitly: `always()` keeps a SKIPPED build (full mode, where the job never runs) from cascading into skipped shards, while the guard still requires `success` or `skipped`, so a genuine build FAILURE stops the shards. The shard also verifies the downloaded binary is runnable and exports PERRY_BIN / PERRY_RUNTIME_DIR. #8684 inlines dtolnay/rust-toolchain and SHA-pins every other third-party action. Verified no job and no gate is dropped: the single removed step is the fast-mode archive build, which moved into gap-suite-build. No version bump. Co-authored-by: Ralph Küpper <ralph@skelpo.com>
Contributor
|
Landed on For a CI-mechanics PR the risk I care about is silently-dropped coverage, so I diffed the job and step sets against Validated on the merged result: all 30 lint checkers, codegen 1202/0, runtime 2655/0, perry-bin 1031/0. Thanks! |
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
2 participants
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.
Summary
Reduces the third-party action trust surface in
.github/: the most common action is inlined instead of depended on, and every remaining tag-pinned action gets pinned to a commit SHA. Fixes a real, currently-broken reference found along the way.What changed and why
dtolnay/rust-toolchain@stableappeared 45 times across 23 workflow files, and every single call site passed the sametoolchain: 'nightly-2026-08-20'thatrust-toolchain.tomlat the repo root already pins. Installing a pinned toolchain is onerustup toolchain installcommand, so there is no reason to depend on a third-party action for it. I replaced every occurrence with an inlinerun: rustup toolchain install nightly-2026-08-20 --profile minimalstep, translating each site'scomponents:/targets:inputs into the matching--component/--targetflags so the installed toolchain is identical to what the action produced.Every other third-party or
actions/*reference that was still pinned to a mutable tag (actions/checkout,actions/cacheand itsrestore/saveforms,actions/setup-node,actions/upload-artifact,actions/download-artifact, the three GitHub Pages actions,ilammy/msvc-dev-cmd,mozilla-actions/sccache-action,Swatinem/rust-cache,oven-sh/setup-bun,taiki-e/install-action) now pins the commit SHA that tag currently resolves to, with the tag kept as a trailing comment for readability. A tag can be silently repointed after review lands; a SHA can't.While resolving these I found
taiki-e/install-action@v3does not exist upstream at all — that action has never shipped av3, the latest release isv2.86.6.coverage.yml'scargo-llvm-covinstall step has failed withstartup_failureon every scheduled run for weeks as a result. Pinned to the real latest release instead of the tag that never existed.Changes
The first commit inlines
dtolnay/rust-toolchainacross 23 workflow files. The second commit SHA-pins every other newly-identified tag reference across 30 files, including thetaiki-e/install-actionfix described above.Related issue
n/a
Test plan
I ran
actionlintagainst every touched workflow file before and after each commit and diffed the findings: the only differences are line-number shifts from the shorter inlined blocks, with zero new findings introduced. I confirmed every workflow file still parses as valid YAML after each transform. I resolved each action's SHA directly against the GitHub API (git/refs/tags/<tag>) rather than guessing, and spot-checked that the resulting pins match SHAs already in use elsewhere in the same files where that tag already appeared pinned.cargo build --releaseand the workspace test suite are not applicable, since no Rust source changed.Checklist
I have not bumped the workspace version or edited CLAUDE.md or CHANGELOG.md. My commits follow the
chore:prefix convention used in the log. I have read CONTRIBUTING.md and agree to the Code of Conduct.Summary by CodeRabbit