bazel-contrib / bazel-contrib/setup-bazel
Setting `--output_base` in the home `.bazelrc` causes rules_bazel_integration_test tests to deadlock
- Dominant language
- JavaScript
- Stars
- 83
- Forks
- 32
- PR merge metrics
- No merged PRs in 30d
Description
Currently, setup-bazel set the bazel output base (`/home/runner/.bazel` by default) in the home `.bazelrc` (`/home/runner/.bazelrc`).
This is causing deadlocks when using [rules_bazel_integration_tests](https://github.com/bazel-contrib/rules_bazel_integration_test):
- the initial invocation uses `/home/runner/.bazel` as its output base, taking the lock on this location.
- a bazel integration test runs another bazel invocation as part of its test case. It processes the home `.bazelrc` and also settles on `/home/runner/.bazel` as its output base. This inner invocation tries to kill the existing bazel server using that location but deadlocks doing so.
Example of logs when the inner bazel invocation is run with `--client_debug`:
```
$TEST_TMPDIR defined: output root default is '/home/runner/.bazel/execroot/_main/_tmp/2dbce8196efc9d097018b00a08eb66fa' and max_idle_secs default is '15'.
[INFO src/main/cpp/option_processor.cc:407]] Looking for the following rc files: /etc/bazel.bazelrc,/home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/tests/integration_tests/my_integration_test.runfiles/_main/tests/integration_tests/example_workspaces/my_integ_test_workspace/.bazelrc,/home/runner/.bazelrc
[INFO src/main/cpp/rc_file.cc:56]] Parsing the RcFile /home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/tests/integration_tests/my_integration_test.runfiles/_main/tests/integration_tests/example_workspaces/my_integ_test_workspace/.bazelrc
[INFO src/main/cpp/rc_file.cc:56]] Parsing the RcFile /home/runner/.bazelrc
[INFO src/main/cpp/blaze.cc:1509]] Debug logging requested, sending all client log statements to stderr
[INFO src/main/cpp/blaze.cc:1385]] Acquired the client lock, waited 0 milliseconds
[USER src/main/cpp/archive_utils.cc:227]] Extracting Bazel installation...
[7 / 8] Testing //tests/integration_tests:my_integration_test; 0s local
[INFO src/main/cpp/blaze.cc:1585]] Trying to connect to server (timeout: 30 secs)...
[INFO src/main/cpp/blaze.cc:996]] Killing running server because it is using another version of Bazel
[INFO src/main/cpp/blaze.cc:1756]] Shutting running server with RPC request
```
Workarounds are always trivial because the home bazelrc has a relatively high precedence (it has higher precedence than the workspace .bazelrc, cf. https://bazel.build/run/bazelrc). Moreover, the `--output_base` option cannot be unset once it's been set.
Overall, I wonder if using the home bazelrc for this is an anti-pattern? Each bazel workspace is expected to use a different output base, and although many repositories only build a single Bazel workspace, some build multiple ones. I do appreciate there is a practical element to doing it this way, though.
Contributor guide
Research direction
Start by inspecting how setup-bazel writes /home/runner/.bazelrc and sets --output_base, then reproduce the nested Bazel invocation described with rules_bazel_integration_tests. Compare the outer and inner output-base behavior; done means integration tests can launch another Bazel invocation without deadlocking while the action still configures Bazel correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript
- Domain
- build-system, ci-cd
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100