Download of JDK from the Elastic catalog instead of Adoptium #15514
Conversation
…alog to get metadata, and return the catalog download link instead of directly pointing to Adoptium API
andsel
changed the title
andsel
changed the title
andsel
changed the title
| // arch x86_64 never used, only aarch64 if macos | ||
| def url = "https://jvm-catalog.elastic.co/jdk/latest_adoptiumjdk_${major}_${osName}" | ||
|
|
||
| // Append the cpu's arch only if Mac on aarch64, all the other OSes doesn't have CPU extension |
There was a problem hiding this comment.
Hm, I don't think that's correct, for example for Linux aarch64 artifacts we have https://jvm-catalog.elastic.co/jdk/latest_adoptiumjdk_17_linux_aarch64, for Windows e.g. /jdk/latest_zulu_19_windows_aarch64 or even 32bit variants like /jdk/latest_adoptopenjdk_16_windows_x86_32.
Or maybe I musunderstood the comment as in we don't need it, but for DRA my understanding is that we need all combinations e.g. in https://buildkite.com/elastic/logstash-dra-snapshot-pipeline/builds/98#018b6ef8-3807-4234-8cd3-10b2e9c0fb8e/70-298 ?
There was a problem hiding this comment.
I can't use a generalized URL template like https://jvm-catalog.elastic.co/jdk/latest_adoptiumjdk_${major}_${osName}_${arch} because the url https://jvm-catalog.elastic.co/jdk/latest_adoptiumjdk_17_linux_x86_64 return a
Could not find download for latest_adoptiumjdk_17_linux_x86_64
But the https://jvm-catalog.elastic.co/jdk/latest_adoptiumjdk_17_linux return the x86_64 artifact.
So we could use the arch format iff it's an ARM (not only for MacOS but also for Linux).
WDYT?
There was a problem hiding this comment.
I agree. We can use the default URL for x86_64 and use a suffix (aarch64 in our case) for the specific aarch64 artifacts for macOS, Linux or Windows.
There was a problem hiding this comment.
LGTM
As discussed elsewhere, I triggered an aarch64 build which run fine with this PR: https://buildkite.com/elastic/logstash-pull-request-pipeline/builds/151 (compared to e.g. https://buildkite.com/elastic/logstash-aarch64-pipeline/builds/24 which failed on Friday).
Would be nice to check if windows building works fine as well e.g. by triggered the main snapshot DRA job using pull/15514/merge, but from my PoV we are good here.
|
SonarQube Quality Gate
|
💚 Build Succeeded
History
cc @andsel |
|
@logstashmachine backport 8.11 |
* Adapted the JDK's download URL creation to intereact with Elastic catalog to get metadata, and return the catalog download link instead of directly pointing to Adoptium API * Silenced the Download task of JDK to print the full url (cherry picked from commit 73daec0)
…#15515) * Adapted the JDK's download URL creation to intereact with Elastic catalog to get metadata, and return the catalog download link instead of directly pointing to Adoptium API * Silenced the Download task of JDK to print the full url (cherry picked from commit 73daec0) Co-authored-by: Andrea Selva <[email protected]>
|
@logstashmachine backport 7.17 |
* Adapted the JDK's download URL creation to intereact with Elastic catalog to get metadata, and return the catalog download link instead of directly pointing to Adoptium API * Silenced the Download task of JDK to print the full url (cherry picked from commit 73daec0)
Release notes
[rn:skip]
What does this PR do?
Adapted the JDK's download URL creation to intereact with Elastic catalog to get metadata, and return the catalog download link instead of directly pointing to Adoptium API
Why is it important/What is the impact to the user?
Let the CI work smoothly, using the unified source of JDKs.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files (and/or docker env variables)[ ] I have added tests that prove my fix is effective or that my feature worksAuthor's Checklist
How to test this PR locally
Use Gradle task:
using differn OSes (
windows,linux,darwin) and different CPU architectures (x86_64,arm64).arm64is valid only for MacOS (Darwin).Related issues