bazel: Use hermetic JDK 11#1863
Merged
buildbreaker merged 1 commit intoenvoyproxy:mainfrom Oct 20, 2021
Merged
Conversation
brentleyjones
commented
Oct 5, 2021
| unzip $sources_jar -d $sources_dir > /dev/null | ||
|
|
||
| $java \ | ||
| --add-opens java.base/java.util=ALL-UNNAMED \ |
Contributor
Author
There was a problem hiding this comment.
Contributor
Author
|
Failures seem to be related to the Java 8 |
6c92374 to
75d8ad3
Compare
Contributor
Author
|
Seems I'm getting an error in the tests: https://github.com/envoyproxy/envoy-mobile/pull/1863/checks?check_run_id=3815098949#step:6:725 |
53fc12f to
0eb5dbf
Compare
fb18b2b to
43fa8d7
Compare
This improves caching, while also removing the need to manage a local JDK. Signed-off-by: Brentley Jones <[email protected]>
43fa8d7 to
a54044a
Compare
Contributor
Author
|
Fixed the crash above by using the jni header that comes with the selected JDK. |
Member
|
👏 @brentleyjones next up hermetic NDK??? :) |
Contributor
Author
|
I do have an idea for that, it's just less out of the box. |
Member
I will buy you a bottle of your beverage of choice if you can get us to a fully hermetic build. :) |
jpsim
added a commit
to jpsim/envoy-mobile
that referenced
this pull request
Oct 21, 2021
* origin/main: [Apple] Guess string encoding when creating an NSString with UTF8 fails (envoyproxy#1891) Link android dev document in a doctree (envoyproxy#1892) bazel: Remove rules_jvm_external dep on JAVA_HOME (envoyproxy#1890) release: 0.4.3.20211020 (envoyproxy#1887) Add debug instructions and sample bazelproject (envoyproxy#1888) bazel: Use hermetic JDK 11 (envoyproxy#1863) envoy: bump upstream to c687308 (envoyproxy#1886) docs: how to test with local envoy (envoyproxy#1876) network: implement initial heuristic for binding alternate interface (envoyproxy#1858) Assign an int to each log level (envoyproxy#1885) envoy: bump upstream to a5b3af2 (envoyproxy#1884) android: stub out jni logging by default (envoyproxy#1879) CI: Add local JDK to asan/tsan builds (envoyproxy#1878) Make JniBridgeUtility public (envoyproxy#1880) swift: Fix Swift version in podspec (envoyproxy#1875) Signed-off-by: JP Simard <[email protected]>
This file contains hidden or 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
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.
Description: Using hermetic JDK 11 with Bazel. This improves caching, while also removing the need to manage a local JDK.
Risk Level: Low.
Testing: Built locally.
Docs Changes: N/A
Release Notes: N/A
I feel the risk is low, as this only changes the Java Runtime used, but not the toolchain used for compiling (which would still be target version of 8).