ci: shut down the Bazel server after each test leg - #1547
Conversation
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011fhMDeQAA118gVquCvqVda
|
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 18:37:00 UTC 2026 ✅ 44 successful tasks
⏱ Last updated Thu Sep 17 18:52:48 UTC 2026 · 📊 GitHub API quota 1,098/7,700 (14% used, resets in 9m) |
py_binary startup benchmark
sys.path quality
Bazel analysis benchmark
py_image_layer benchmark
|
The bazel-8 leg of
test (e2e/rules-python-protobuf, bazel-8)in run 35181795460 failed withalthough
actions/checkouthad rungit clean -ffdxandgit reset --hard, the committed lockfile islockFileVersion: 24(Bazel 8.6.0) at every commit involved, and the job's BEP recordsbuild_tool_version: 8.6.0. The retry passed on a different runner.Cause. The runner's previous job was the bazel-9 leg of the same workspace, from the run that
cancel-in-progresskilled when the PR was force-pushed. Its Bazel 9.2.0 server stayed alive in the output base, which every leg on a persistent runner shares. When the next job's Bazel 8.6 client found a server from another install base it killed it the wayblaze.ccalways does: by sending it ashutdowncommand.BazelLockFileModule.afterCommandruns onshutdowntoo, and Bazel 9.2 had parsed the committed v24 file as "old version, treat as empty", so its recomputed lockfile always differed from what it last read and it wrote alockFileVersion: 28file into the workspace. That happened after the checkout restored the file and one second before the test command read it with--lockfile_mode=error.Reproduced locally with bazelisk 8.6.0 and 9.2.0 on one output base:
Change. Every
testleg ends withbazel shutdownon self-hosted runners, including on failure and cancellation. The lockfile rewrite then happens inside the job that owns the server, before the next job's checkout restores the committed file.USE_BAZEL_VERSIONis job-level, so the shutdown uses the leg's own Bazel. GitHub-hosted legs get a fresh VM per job and skip the step.A job that is cancelled or crashes before this step still leaves its server behind.
Changes are visible to end-users: no
Test plan
testlegs show the new step and pass. Reproducing the original failure needs the bazel-8 leg to land on a runner that just ran the bazel-9 leg of the same workspace, which the scheduler does not guarantee; the local reproduction above covers the mechanism.🤖 Generated with Claude Code
https://claude.ai/code/session_011fhMDeQAA118gVquCvqVda