[8.19] (backport #18733) Respect ARCH env var when downloading JDK via gradle#18748
Merged
[8.19] (backport #18733) Respect ARCH env var when downloading JDK via gradle#18748
Conversation
* Respect ARCH env var when downloading JDK via gradle With the refactor of gradle to be the root of every orchestration task https://github.com/elastic/logstash/pull/18471/changes the artifactAll task depends on copyJdk, which calls downloadJdk. downloadJdk uses selectArch() to determine which JDK to download which results in the ARCH env var to be ignored. Given we build aarch64 packages on x86_64 in CI we always end up with the x86_64 jdk. This commit updates selectArch() to respect the env var * actually set the ARCH env var * WIP: downlaod all JDK for a specific ARCH * fix container builds and remove dead code * Add exhaustive tests for linux (deb) aarch64 artifacts This commit extends the aarch64 pipeline to build a `.deb` for `aarch64` on an x86 VM then run the exhaustive tests on `aarch64` VM with the `.deb`. This replicates how artifacts are prepared in DRA on x86. This is net new in that it adds exhaustive tests for an `aarch` platform. This would have caught a recent packaging bug. More thourough tests will be added in the future, this is just a first step to get toward that goal. actually build arm (cherry picked from commit 7f1ca8e) # Conflicts: # build.gradle
Contributor
Author
|
Cherry-pick of 7f1ca8e has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Contributor
🤖 GitHub commentsJust comment with:
|
Member
💚 Build Succeeded
History
cc @donoghuc |
donoghuc
added a commit
to donoghuc/logstash
that referenced
this pull request
Feb 6, 2026
During the backport of elastic#18748 the ubi 8 task which does not exist in 9.x/main was missed. This updates the task to use the new dependency. The rest of the tasks will do the right thing.
mashhurs
pushed a commit
that referenced
this pull request
Feb 6, 2026
During the backport of #18748 the ubi 8 task which does not exist in 9.x/main was missed. This updates the task to use the new dependency. The rest of the tasks will do the right thing.
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.
Release notes
Ship the correct bundled JDK for all logstash artifacts.
What does this PR do?
With the refactor to make gradle the entry point to every CI task #18471 (and to not have any cyclical dependencies) the
copyJdktask ended up satisfying the dependency for all tasks for which it was needed. Previously, rake would call back in to gradle and continuously download and delete JDKs. This resulted in a bug where a single JDK was shipped for ALL artifacts.In practice, CI for building artifacts is split across:
The combination of selecting the architecture and operating system were overly complex and made assumptions about the host os/arch.
New approach
Now we just download all the JDKs for a specific arch up front and then package the correct one based on the target artifact (NOT the host). The
copyAllJdkstask usesgetTargetPlatforms()which reads the ARCH environment variable:ARCH=x86_64downloads linux-x64, windows-x64, darwin-x64 JDKsARCH=aarch64downloads linux-aarch64, darwin-aarch64 JDKsEach platform gets its own download task (downloadJdk_linux_aarch64) and output folder (jdk-linux-aarch64/). The rake packaging scripts select the correct JDK folder based on the artifact being built.
Why is it important/What is the impact to the user?
Arm/aarch64/windows/mac users can now run logstash installed from
.rpm,.tar,.debartifacts.Validation steps:
I checked out a VM we use as a builder and build artifacts for all platforms for both architecture sets:
The following script is used to check JDKs
For x86_64
ARCH=x86_64 ./gradlew artifactAll:The build dir contains
The validate script results:
For arm
ARCH=aarch64 ./gradlew artifactAll:The build dir contains
The validate results:
Similarly I build container artifacts (which we have better test coverage for) and validated those worked for arm (we have a ton of test coverage in CI for x86).
Closes #18728
This is an automatic backport of pull request #18733 done by Mergify.