CI: cache the bindgen-cli binary instead of rebuilding it every run#14966
Merged
Conversation
cargo install bindgen-cli ran before the rust-cache action. rust-cache prunes binaries that already exist in ~/.cargo/bin before its main step runs (it assumes they are pre-installed tooling), so bindgen was deleted from every cache save and recompiled from scratch (~55s) on every BoringSSL and AWS-LC job. Moving the install after the cache restore lets rust-cache keep the binary (cache-bin defaults to true), and on warm caches cargo install sees the binary is already installed and skips the build. The cache key is bumped so the improvement takes effect immediately rather than waiting for the next Cargo.lock rotation (rust-cache does not re-save on a primary key hit). https://claude.ai/code/session_014StKTjk7GBcVdiWKimEsQb
reaperhulk
approved these changes
Jun 7, 2026
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
3 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.
What
Moves
cargo install bindgen-clito run after the rust-cache step in thelinuxjob, and bumps the shared cache key.Why
Looking at recent CI timings, every BoringSSL/AWS-LC matrix job (4 jobs per run) spends ~55s compiling bindgen-cli from source on every single run, despite a warm rust cache.
The cause:
Swatinem/rust-cachesnapshots~/.cargo/binat the start of its main step and, before saving the cache, prunes any binaries that already existed at that point (it assumes they're pre-installed tooling, seecleanBin). Since thecargo install bindgen-clistep currently runs before the cache action, the binary is pruned from every cache save and rebuilt from scratch on every run.With the install moved after the cache action:
cache-bindefaults totrue, which covers~/.cargo/binplus.crates.toml/.crates2.json)cargo install bindgen-clisees the binary is already installed and becomes a quick no-op (just an index check)The cache key bump (
-4→-5) is needed because rust-cache doesn't re-save on a primary key hit — without it, the existing bindgen-less caches would be restored and never refreshed until the next Cargo.lock rotation.Expected impact
~50s saved on each of the 4 boringssl/aws-lc jobs per CI run (these are among the slowest
linuxjobs at 3.4–3.9 min).Note: the first CI run on this PR is a cold-cache run (key bump), so it will be slower than baseline. The second push demonstrates the warm-cache behavior — check the
rustup run stable cargo install bindgen-clistep duration on the boringssl/aws-lc jobs.https://claude.ai/code/session_014StKTjk7GBcVdiWKimEsQb
Generated by Claude Code