Skip to content

testbazel: update to Bazel 9.1.0#11966

Draft
dan-stowell wants to merge 7 commits intomasterfrom
test-with-bazel-9
Draft

testbazel: update to Bazel 9.1.0#11966
dan-stowell wants to merge 7 commits intomasterfrom
test-with-bazel-9

Conversation

@dan-stowell
Copy link
Copy Markdown
Contributor

Add Bazel 9.1.0 http_file entries and switch testbazel to use 9.1.0 instead of 8.5.0.

dan-stowell and others added 5 commits April 23, 2026 12:23
Add Bazel 9.1.0 http_file entries and switch testbazel to use 9.1.0
instead of 8.5.0.

Co-authored-by: Shelley <shelley@exe.dev>
- Add explicit load() statements for sh_binary/sh_test in test BUILD
  files, since these are no longer native rules in Bazel 9.
- Have testbazel.InitModule inject a bazel_dep on rules_shell into
  MODULE.bazel when running against Bazel 9+.
- In remote_bazel_test, switch the cc_binary tests from a WORKSPACE
  setup to a bzlmod MODULE.bazel with a rules_cc bazel_dep.

Co-authored-by: Shelley <shelley@exe.dev>
Co-authored-by: Shelley <shelley@exe.dev>
On Bazel 9, the prewarmed MODULE.bazel.lock is generated on the platform
where extract_bazel_installation runs (typically linux-x86_64 via remote
execution). When the inner-bazel test runs on a different host platform
(macOS or linux-arm64), bzlmod needs to resolve a handful of
platform-specific entries that aren't in the prewarmed lockfile; with
--lockfile_mode=error, this was causing tests like bazel_rbe_test,
build_event_protocol_test, and cli_test to hang (and ultimately time out)
on those platforms.

Switch to --lockfile_mode=update for Bazel 9 so the inner-bazel can fill
in platform-specific lockfile entries (using the shared repository_cache
which is already populated during prewarm). Keep --lockfile_mode=error
for older Bazel versions, which is what the existing tests rely on.

Co-authored-by: Shelley <shelley@exe.dev>
dan-stowell and others added 2 commits April 23, 2026 19:17
Bazel 9's bzlmod resolution can need network access for
platform-specific module sources, which is why the prewarmed lockfile
(generated on linux-x86_64 via remote exec) was not sufficient for
tests running on macOS / linux-arm64. We previously worked around this
by relaxing the inner bazelrc to --lockfile_mode=update, which lets
tests silently reach out to the Bazel Central Registry.

Switch to the 'bazel vendor' approach instead:

- extract_bazel_installation now runs 'bazel vendor --vendor_dir=...'
  alongside 'bazel fetch //...', emitting a platform-neutral vendor
  tree into $OUT_DIR/vendor_dir. A dangling bazel-external convenience
  symlink left by 'bazel vendor' is removed, and VENDOR.bazel is
  asserted to contain no absolute paths so the artifact is relocatable.

- testbazel.go points inner invocations at that vendor dir via
  --vendor_dir=... and re-enables --lockfile_mode=error on Bazel 9+.
  The prewarmed repository_cache stays configured as a belt-and-
  suspenders net for any WORKSPACE-style (non-bzlmod) http_file
  fetches.

This guarantees the inner Bazel makes zero BCR/network requests for
bzlmod, on any host OS/arch, and is exec-platform agnostic -- so a
single linux-x86_64 remote execution of extract_bazel_installation
produces artifacts consumable by darwin-arm64 and linux-arm64 tests
alike.

Co-authored-by: Shelley <shelley@exe.dev>
testbazel is pinned to a single Bazel version (9.1.0). There's no need
for strings.HasPrefix(Version, "9.") branches -- the Bazel 9 code paths
are always taken. Collapse the conditionals in InitModule and
BinaryPath.

Co-authored-by: Shelley <shelley@exe.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant