Repository navigation
Disable Bazel disk cache - #2864
Merged
MarcusSorealheis merged 2 commits intoOct 2, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This comment has been minimized.
This comment has been minimized.
palfrey
force-pushed
the
reduce-bazel-disk-cache
branch
from
October 2, 2026 10:58
e5dc17f to
9efeb15
Compare
palfrey
marked this pull request as ready for review
October 2, 2026 11:09
This was referenced Oct 2, 2026
b7r6
added a commit
to b7r6/nativelink
that referenced
this pull request
Oct 3, 2026
…y (--config=nl-toolchain) Realizes the warm-cache contract TraceMachina#2874 sets up. That change keys the Bazel Dev (nix) lane's reads on the endpoint-free nl-toolchain config — the hermetic LLVM platform + downloaded Rust toolchains that nl-rbe already uses — because toolchains keyed on downloaded content produce identical action digests on a bare runner, inside nix develop, or on a remote worker. But nobody writes that digest space yet: the trusted main-push Bazel 9 lane (the only holder of a write key) warms with bare --extra_toolchains, host-toolchain keys the Dev lane can never hit. Switch the Bazel 9 lane from --extra_toolchains=@rust_toolchains//:all to --config=nl-toolchain (which contains that same line plus the @llvm platform pin). On main pushes this lane becomes the warmer for the hermetic digest space; on PRs it reads from it. The Bazel 8 lane is untouched (separate, lockfile_mode=off digest space). Transition cost, stated honestly: the first runs after this merges are cold for everyone until the first main push warms the new key space — one build. Measured so far is key ALIGNMENT, not the warm win: the aquery proof run shows nix+nl-toolchain command lines byte-identical to bare-runner nl-toolchain with no /nix/store references (https://github.com/b7r6/nativelink/actions/runs/37059855343). The warm hit-rate itself cannot be measured from a fork (no write credentials); projected from the Bazel 9 lane's current warm behavior, the Dev lane drops from ~11 min to roughly the Native lane's ~5 min. Stacked on TraceMachina#2874 (requires its nl-toolchain config). Builds on the remote-cache lanes and @palfrey's TraceMachina#2864 disk-cache handling. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This branch was successfully deployed
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.
What and why
On some builds e.g https://github.com/TraceMachina/nativelink/actions/runs/36993015164/job/110793339059?pr=2684 the Bazel disk cache is taking a stupid amount of time to save/restore. Of that 18 minute build, ~16 minutes were just the Bazel cache, which is really not worth it.
How was this verified?
CI, seeing if it goes faster. https://github.com/TraceMachina/nativelink/actions/runs/36997151732/job/110806385731?pr=2864 which is the same build step as the problematic example took ~4 minutes instead.
Risk
Low. Primary risk is slower builds, but not broken ones (provided this PR cleanly builds)
AI assistance
None