Build Java SDK e2e example bundles natively in CI#69794
Draft
jason810496 wants to merge 1 commit into
Draft
Conversation
The java_sdk e2e mode and the lang-SDK k8s test solved the same cold-build problem two different ways (containerized Gradle with a repo-local cache vs host toolchain with salted home-dir caches), which a review follow-up on apache#69239 asked to reconcile. Converge the e2e mode on the apache#69411 native-toolchain convention: CI provisions the JDK with actions/setup-java and caches ~/.gradle, dropping the per-run eclipse-temurin image pull and the --network=host Gradle lock-handover workaround; local runs keep the containerized build so a dev host still needs no JDK.
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-3-test
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
1 participant
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.
related:
Why
#69239 (java_sdk e2e mode) and #69411 (lang-SDK k8s test) solved the same cold-Gradle-build problem two different ways: containerized builds with a repo-local cache vs. host-toolchain builds with salted home-dir caches.
This converges the e2e
java_sdkmode on the #69411 native-toolchain convention.How
LANG_SDK_NATIVE_TOOLCHAIN=true(the same switch the k8s job uses) so the conftest invokes the host./gradlewinstead ofdocker run eclipse-temurin:17-jdk— the build helpers take anativeflag mirroring the Speed up lang-SDK k8s test by building Go/Java natively in CI #69411 k8s helpers. This drops the per-run toolchain-image pull and the container workarounds (--network=hostlock handover,HOMEoverride). Local runs keep the containerized build, so a dev host still needs no JDK.actions/setup-java, versioned by the existingjava-sdk-versionbuild-info output, ask8s-tests.ymlalready does.~/.gradlewith a salted key (e2e-java-sdk-gradle-v1-, bump to invalidate), kept separate from the k8s job's key since the e2e tree carries ~1GB of Spark the k8s job never needs.Was generative AI tooling used to co-author this PR?