You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BCR CI fails for repositories that build Java libraries with Bazel 6.x as part of their presubmit, due to a crash in something called Turbine that appears to be an internal component of Bazel's Java toolchain.
This failure doesn't reproduce for me on any of the actual machines I test on (macOS x86-64, macOS arm64, Ubuntu 20.04 x86-64) so I think it's something specific to the way the container images are constructed, such as an unusual combination of Java and Bazel versions.
This makes the PR process frustrating for modules that have Java functionality, because the presubmit requires manual approval to run but it fails for something that I don't test for and for which verifying a fix is difficult.
Example affected PRs:
Add javacc and javaparser #2728, which was solved by adding a dependency on rules_java(version = "6.0.0") on the theory that this version included a fixed build of Turbine.
Suspected cause: the container image has Java 21, but Bazel 6.x bundled Java rules are intended for Java 11 and 18.
This means a possible solution is to configure the CI scripts so that when running the build with older versions of Bazel, they set a flag to use a non-host JDK. I verified the "hello world" example builds fine with Bazel 6.x when run with remotejdk_11 and remotejdk_18.
# bazel build //:HelloBin.jar --java_runtime_version=remotejdk_11
[...]
Target //:HelloBin.jar up-to-date:
bazel-bin/HelloBin.jar
[...]
# bazel build //:HelloBin.jar --java_runtime_version=remotejdk_18
[...]
Target //:HelloBin.jar up-to-date:
bazel-bin/HelloBin.jar
[...]
root@desktop:/src/e2e# bazel build //:HelloBin.jar --java_runtime_version=remotejdk_21
INFO: Build option --java_runtime_version has changed, discarding analysis cache.
ERROR: /src/e2e/BUILD.bazel:6:12: While resolving toolchains for target //:HelloBin: No matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type.
To debug, rerun with --toolchain_resolution_debug='@bazel_tools//tools/jdk:runtime_toolchain_type'
If platforms or toolchains are a new concept for you, we'd encourage reading https://bazel.build/concepts/platforms-intro.
ERROR: Analysis of target '//:HelloBin.jar' failed; build aborted:
[...]
root@desktop:/src/e2e# java -version
openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment (build 21.0.2+13-Ubuntu-120.04.1)
OpenJDK 64-Bit Server VM (build 21.0.2+13-Ubuntu-120.04.1, mixed mode, sharing)
What happened?
BCR CI fails for repositories that build Java libraries with Bazel 6.x as part of their presubmit, due to a crash in something called Turbine that appears to be an internal component of Bazel's Java toolchain.
This failure doesn't reproduce for me on any of the actual machines I test on (macOS x86-64, macOS arm64, Ubuntu 20.04 x86-64) so I think it's something specific to the way the container images are constructed, such as an unusual combination of Java and Bazel versions.
This makes the PR process frustrating for modules that have Java functionality, because the presubmit requires manual approval to run but it fails for something that I don't test for and for which verifying a fix is difficult.
Example affected PRs:
rules_java(version = "6.0.0")
on the theory that this version included a fixed build of Turbine.Version
Development (host) and target OS/architectures:
Happening in BCR CI under an unknown set of conditions, so Linux/macOS/Windows probably.
Output of
bazel --version
:bazel 6.5.0
, but possibly also affects some Bazel 7.x versions (I noticed a 7.x failure at one point, in PR 2904)Version of relevant rules from the
WORKSPACE
orMODULE.bazel
file:n/a
Language(s) and/or frameworks involved:
Java
How to reproduce
Using the same
gcr.io/bazel-public/ubuntu2004
OCI container image as BCR CI runs, I was able to reproduce the issue with a "hello world" Java library.Building the Java targets will involve Turbine to get involved and then crash:
Building with
--nojava_header_compilation
(which if I understand correctly turns off Turbine) works:Any other information?
No response
The text was updated successfully, but these errors were encountered: