Add --{no,}autodetect_server_javabase. #12542
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want bazel to fail to start instead of falling back to a host JRE/JDK. We are using a hermetic JDK and the embedded JRE, so there should be no need to use anything from the host. We've debugged enough cases so far where the host installed JDK was buggy and causing random crashes on specific machines. Fixes: bazelbuild#12451
AustinSchuh
requested review from
aiuto,
floriographygoth,
gregestren and
jin
as code owners
comius
requested review from
comius
and removed request for
jin,
aiuto,
gregestren and
floriographygoth
|
It should be pretty easy to make the test pass, but can you confirm the approach looks sane? |
Yes, it's ok. Mind also adding a test for it? This will ensure that somebody else won't break the feature later. There are integration tests in //src/test/shell/integration. statup_options or java_integration_test should get you started, but there is no integration test on //src:bazel_nojdk, so you'll need to set it up. |
|
Sure, done. That was surprisingly easy. Tested both normal and nojdk bazel with --autodetect_server_javabase and --noautodetect_server_javabase. |
FATAL: The install_base directory '/var/lib/buildkite-agent/bazeltest/install_base' contains a different Bazel version (found aa41a738151267f7716fdef640010dd7 but this binary is 8dc389309eace6214919196718842380). Remove it or specify a different --install_base.
comius
approved these changes
Dec 11, 2020
|
Nice implementation, thanks for your effort! Sorry for the delay. |
frc971-automation
pushed a commit
to frc971/971-Robot-Code
that referenced
this pull request
Dec 13, 2020
This is the upstream rc6 branch with two cherry-picks: Fix a couple of bugs with Incompatible Target Skipping bazelbuild/bazel#12560 Add --{no,}autodetect_server_javabase bazelbuild/bazel#12542 This patch also uses the new --noautodetect_server_javabase flag. Change-Id: I7a397e4a9f17b942d0f81c7affb829d2de385a30
meisterT
pushed a commit
that referenced
this pull request
Jan 12, 2021
We want bazel to fail to start instead of falling back to a host JRE/JDK. We are using a hermetic JDK and the embedded JRE, so there should be no need to use anything from the host. We've debugged enough cases so far where the host installed JDK was buggy and causing random crashes on specific machines. Fixes: #12451 Closes #12542. PiperOrigin-RevId: 347411720
ulfjack
pushed a commit
to EngFlow/bazel
that referenced
this pull request
Mar 5, 2021
We want bazel to fail to start instead of falling back to a host JRE/JDK. We are using a hermetic JDK and the embedded JRE, so there should be no need to use anything from the host. We've debugged enough cases so far where the host installed JDK was buggy and causing random crashes on specific machines. Fixes: bazelbuild#12451 Closes bazelbuild#12542. PiperOrigin-RevId: 347411720
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We want bazel to fail to start instead of falling back to a host
JRE/JDK. We are using a hermetic JDK and the embedded JRE, so there
should be no need to use anything from the host. We've debugged enough
cases so far where the host installed JDK was buggy and causing random
crashes on specific machines.
Fixes: #12451