build(bazel): migrate the monorepo toolchain from 8.6.0 to 9.1.1#276
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
🚧 Files skipped from review as they are similar to previous changes (6)
📝 WalkthroughWalkthroughThe project upgrades Bazel to 9.1.1, updates protobuf and Java tooling, regenerates Maven dependency metadata, adjusts Bazel compatibility settings, and imports required shell-test and Java provider rules. ChangesBazel upgrade and build integration
Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
🛡️ CodeQL Analysis🚨 Found 2 issue(s) Severity Breakdown:
📋 Top Issues🔗 View full details in Security tab 🕐 Last updated: 2026-07-20 22:28:22 UTC | Commit: 2da97b8 |
sbaum1994
approved these changes
Jul 20, 2026
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.bazelrc (1)
137-140: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winRemove the stale Merkle-cache documentation.
The configuration flags were removed, but these comments still claim that a 10,000-entry Merkle tree cache is configured. Update or remove this block so operators are not misled about the active Bazel 9 settings.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.bazelrc around lines 137 - 140, Remove the stale Merkle-cache comment block in the Bazel configuration, including its claims about 10,000-entry caching and JVM heap usage. Do not add replacement documentation unless it describes active Bazel 9 settings.
🧹 Nitpick comments (1)
.bazelignore (1)
55-57: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy liftPreserve validation coverage for the excluded Spring Boot example.
Because
examples/java-spring-boot-serviceis excluded,bazel build //...no longer exercises the consumer ofrules/java/private/spring_boot.bzl. Add an explicit CI or targeted validation for this example while the temporary exclusion remains.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.bazelignore around lines 55 - 57, Add explicit CI or targeted Bazel validation for examples/java-spring-boot-service so its consumer coverage of rules/java/private/spring_boot.bzl remains exercised while the .bazelignore exclusion is present. Keep the exclusion unchanged and wire validation into the existing repository check mechanism.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.bazelrc:
- Around line 137-140: Remove the stale Merkle-cache comment block in the Bazel
configuration, including its claims about 10,000-entry caching and JVM heap
usage. Do not add replacement documentation unless it describes active Bazel 9
settings.
---
Nitpick comments:
In @.bazelignore:
- Around line 55-57: Add explicit CI or targeted Bazel validation for
examples/java-spring-boot-service so its consumer coverage of
rules/java/private/spring_boot.bzl remains exercised while the .bazelignore
exclusion is present. Keep the exclusion unchanged and wire validation into the
existing repository check mechanism.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 83213f8e-2533-471e-a825-75efdc0804ec
⛔ Files ignored due to path filters (1)
MODULE.bazel.lockis excluded by!**/*.lock,!**/MODULE.bazel.lock
📒 Files selected for processing (6)
.bazelignore.bazelrc.bazelversionMODULE.bazelrules/java/private/spring_boot.bzlsrc/libraries/go/lib/BUILD.bazel
balajinvda
force-pushed
the
chore/bazel-9-1-1
branch
from
July 20, 2026 22:38
2da97b8 to
92eed69
Compare
Bump the root Bazel toolchain to 9.1.1 ahead of the Java (nv-boot-parent) import, which was validated on 9.1.1. This is a repository-wide toolchain change kept separate from the Java import so each is reviewable on its own. Nothing that built on 8.6.0 is disabled: the whole tree still builds on 9.1.1. Bazel 9 removals and their fixes: - .bazelrc: drop --experimental_remote_merkle_tree_cache[_size] (removed in 9; behavior falls back to the default --experimental_remote_discard_merkle_trees). - rules/java/private/spring_boot.bzl: load JavaInfo from @rules_java//java/common (no longer a global). - src/libraries/go/lib/BUILD.bazel: load sh_test from @rules_shell (no longer a global); add the rules_shell module dep. Java rules stack (keeps examples/java-spring-boot-service building on 9.1.1): - contrib_rules_jvm 0.27.0 -> 0.33.0 (0.27.0's spotbugs_config.bzl uses the removed global JavaInfo); rules_jvm_external 6.7 -> 7.0. - Maven hub repositories are now public Central mirrors only. The public GitHub runners cannot resolve the internal Artifactory host, so the pinned closure must fetch from public repos; re-pinned maven_install.json accordingly. Also removes the internal hostname from the public repo. protoc/protobuf alignment: - Bazel 9.1.1 resolves the protobuf module to 33.4. toolchains_protoc 0.6.1 (latest) ships protoc v33.0 but not 33.4, so pin protoc v33.0 (same major, compiles 33.4's protos) and allow the 33.0-vs-33.4 skew via --@com_google_protobuf//bazel/toolchains:allow_nonstandard_protoc. protobuf is declared directly with repo_name com_google_protobuf so that flag resolves. Validated locally: `bazel build //...` completes cleanly on 9.1.1 (fully cacheless), including the Java example. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
balajinvda
force-pushed
the
chore/bazel-9-1-1
branch
from
July 20, 2026 23:10
92eed69 to
d471985
Compare
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.
Why
The nv-boot-parent Java import (coming next) was validated on Bazel 9.1.1, and its rules stack (rules_java 9.x, rules_jvm_external 7.0) needs Bazel 9. Bumping the root toolchain is a repository-wide change that touches the shared remote-cache config and every service's build, so it is split out here as its own reviewable step ahead of the Java import.
What changed
Bazel 9 removed several globals and flags; this migrates the root config:
.bazelversion->9.1.1..bazelrc: drop--experimental_remote_merkle_tree_cache[_size](removed in 9; falls back to the default--experimental_remote_discard_merkle_trees). Add--@com_google_protobuf//bazel/toolchains:allow_nonstandard_protoc(see protoc note).rules/java/private/spring_boot.bzl: loadJavaInfofrom@rules_java//java/common(no longer a global).src/libraries/go/lib/BUILD.bazel: loadsh_testfrom@rules_shell(no longer a global); add therules_shellmodule dep.MODULE.bazel: Bazel 9.1.1 resolves the protobuf module to 33.4.toolchains_protoc0.6.1 (latest) ships protocv33.0but not33.4, so pin protocv33.0(same major, compiles 33.4's protos) and allow the skew.protobufis declared directly withrepo_name = com_google_protobufso the.bazelrcflag resolves..bazelignore: temporarily excludeexamples/java-spring-boot-service(contrib_rules_jvm 0.27.0 predates Bazel 9); re-included by the nv-boot import PR that bumps the Java rules stack.Customer Release Notes
Not customer visible. Build toolchain change.
Plan Summary
Not applicable.
Usage
bazel(bazelisk) reads.bazelversionand fetches 9.1.1 automatically; no local action needed.Testing
bazel build //...completes cleanly on 9.1.1 locally: 5209 total actions, fully cacheless (no remote cache), so the result is independent of the nvcfbarn cache. CI runs the same on the change-aware bazel matrix.Notes
The nvcfbarn remote-cache "lost inputs" transients seen mid-migration are the known cache-resilience issue (handled in CI by
--remote_download_all), not a 9.1.1 problem; the cacheless build proves that.References
NO-REF
Related Merge Requests/Pull Requests
Precedes the nv-boot-parent import (#269), which rebases onto this and re-includes the Java example with the Java rules-stack bump.
Dependencies
Adds module deps
rules_shell 0.8.0and a directprotobuf 33.4(aliasedcom_google_protobuf); bumps the pinned protoc toolchain tov33.0. All from the Bazel Central Registry; no license change.Summary by CodeRabbit
Build Improvements
Dependency Updates
Configuration