ci: run bazel-9 jobs with --lockfile_mode=off - #1545
xangcastle wants to merge 1 commit into
Conversation
The bazel-9 matrix entry ran with `--lockfile_mode=update`. The committed lockfiles are Bazel 8 format (lockFileVersion 24); Bazel 9.2 rejects them in error mode and, in update mode, rewrites them to version 28 inside the checkout. `update` validated nothing, it only wrote. Since the large workspaces moved to Aspect Workflows runners with a persistent workdir shared across jobs, that write leaks: a bazel-8 job scheduled on a runner whose previous job was the bazel-9 job of the same workspace fails with "The version of MODULE.bazel.lock is not supported by this version of Bazel", even though the checkout carries version 24. Seen on #1544, where the same commit failed and then passed on re-run on a different runner. `off` makes Bazel 9 neither read nor write the lockfile, which is what the e2e test.sh scripts already do for their own invocations. Verified locally with Bazel 9.2 on e2e/rules-python-protobuf: module resolution succeeds and the lockfile is untouched.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
✨ Aspect Workflows Tasks📅 Thu Sep 17 05:18:20 UTC 2026 ✅ 44 successful tasks
⏱ Last updated Thu Sep 17 05:36:32 UTC 2026 · 📊 GitHub API quota 2,748/7,700 (36% used, resets in 48s) |
py_binary startup benchmark
sys.path quality
Bazel analysis benchmark
py_image_layer benchmark
|
2 participants
The bazel-9 matrix entry ran with
--lockfile_mode=update. The committed lockfiles are Bazel 8 format (lockFileVersion24); Bazel 9.2 rejects them inerrormode and, inupdatemode, rewrites them to version 28 inside the checkout.updatenever validated anything, it only wrote.Since the large workspaces moved to Aspect Workflows runners (#1542) with a persistent workdir shared across jobs, that write leaks. A bazel-8 job scheduled on a runner whose previous job was the bazel-9 job of the same workspace fails with:
even though the checkout carries version 24. Seen on #1544: the same commit failed on one runner and passed on re-run on another. The failing job's runner log lists
test-e2e-rules-python-protobuf-bazel-9as its previous build.offmakes Bazel 9 neither read nor write the lockfile, which is what the e2etest.shscripts already do for their own invocations.Changes are visible to end-users: no
Test plan
e2e/rules-python-protobuf:bazel mod graph --lockfile_mode=offresolves and the lockfile is untouched, while--lockfile_mode=updaterewrites it to version 28 and--lockfile_mode=errorrejects version 24.