adoptium
EPIC: Support additional alternate binary downloads in Jenkins test pipelines
Use this issue to both document current approach to downloading and installing artifacts for use by test pipelines and to ensure we have a clean/standardized way to add new types of artifacts. Also want to look at whether we can reduce the number of parameters required to address common behaviours.
There are several additional alternate binary downloads (with secondary automated installation steps) that are surfacing as new requirements for our Jenkins scripts.
We have identified several distinct use cases (to continue to align more of the testing under the same approach):
- [ ] RI jvm for jck compiler tests by being able to pass a second URL plus credentials
- [ ] Windows installer testing (See https://github.com/adoptium/installer/issues/559) - pass in an .msi file
- [ ] Linux installer testing - pass in URLs to .rpm | .deb, etc files
- [ ] JRE testing (already supported, USE_JRE boolean parameter) - pass in JRE alongside the JDK for testing
We also already support:
- test_images (TEST_IMAGES_REQUIRED parameter)
- debug_images (DEBUG_IMAGES_REQUIRED parameter)
These being slightly different as they are not a 'second' JDK binary artifact, but their own special type of artifact. In either event, I mention them, to consider if we can clean up our groovy code to handle many more different types of artifact to download and install via our scripts.
Parameters and behaviours relating to this issue are:
SDK_RESOURCE=upstream|nightly|releases|customized TEST_IMAGES_REQUIRED=true|false DEBUG_IMAGES_REQUIRED=true|false USE_JRE=true|false CUSTOMIZED_SDK_URL=[space-separated list of URLs] CUSTOMIZED_SDK_URL_CREDENTIAL_ID=credentialsID_IfURLRequires
and where we make assumptions about test_image, debug_image, jre artifacts being co-located in an upstream job (for SDK_RESOURCE=upstream), or available from the Adoptium API (for SDK_RESOURCE=nightly|releases), and for SDK_RESOURCE=customized, or we can pass space separated URLs in CUSTOMIZED_SDK_URL for different artifacts.
Some notes from the chat that @sophia-guo and I just had (where we talked about how to treat these use cases in a standard way, with a goal to not keep adding an endless number of parameters).
- consider getting rid of all of the individual boolean parameters (TEST_IMAGES_REQUIRED,DEBUG_IMAGES_REQUIRED,USE_JRE,USE_INSTALLER,USE_RI_JDK) into a comma-separated string of 'constant' accepted values, perhaps called something like ADDITIONAL_ARTIFACTS_REQUIRED, which then could be set for all the additional things needed (over and above the JDK binary, which for simplicity and stated below, should always be passed in).
Listed in the order that we can tackle this epic issue:
- [ ] ADDITIONAL_ARTIFACTS_REQUIRED=RI_JDK (~~only with SDK_RESOURCE=customized, since it will not be pulled from an upstream location or from the API as with nightly|releases~~ SL/Mar3rd: this can be supported for all types of SDK_RESOURCE, not just customized) - new feature
- [ ] ADDITIONAL_ARTIFACTS_REQUIRED=INSTALLER - new feature
- [ ] ADDITIONAL_ARTIFACTS_REQUIRED=TEST_IMAGES,DEBUG_IMAGES,JRE - cleanup/reduce params/tech debt issue
- in all cases, the TEST JDK is also wanted (in order to compile test material), so it would always be first in the list of items listed in CUSTOMIZED_SDK_URL when SDK_RESOURCE=customized (and in the case of SDK_RESOURCE=nightly,JDK_IMPL=openj9 where CUSTOMIZED_SDK_URL is utilized to point to artifactory). We will add a table to this issue to outline the behaviours, and uses of the parameters.
Note: Unlike Openj9 Mac binaries, we only get .dmg files for xMac and aMac RI SDKs, meaning we will require a different command to install Mac RI JDKs (for tck).
For RI_JDK, the full path to the binary would be supplied via CUSTOMIZED_SDK_URL, so in the case of Mac JDKs, we can see PLATFORM=x86-64_mac|aarch64_mac and CUSTOMIZED_SDK_URL=https://someServer/pathTo/some.dmg and CUSTOMIZED_SDK_URL_CREDENTIAL_ID would be the credentials required to login to someServer.
For INSTALLER artifacts, we also look at PLATFORM, to know that if PLATFORM=x86-64_windows|x86-32_windows, then we'd be planning to pick up a .msi file. For PLATFORM=someLinux platform, there are multiple types, .rpm/.deb, etc, so we will want to pass those in explicitly via the CUSTOMIZED_SDK_URL parameter. (SDK_RESOURCE=upstream|nightly|releases for INSTALLER files can be out of scope for this issue).
Thought of another use case for RI_JDK
- where we want to pass in 2 Temurin builds to compare them (and write tests related to reproducibility, including the simple one of 'diff' of the 2 builds)
Thanks @sophia-guo for assigning this issue to me. Since the multijvm work is blocked by this, it'd be good to get it implemented asap.
Since RI_JDK is needed first, thanks @Mesbah-Alam for taking that on as the first of the 3 tasks (outlined in https://github.com/adoptium/aqa-tests/issues/4350#issuecomment-1447194197) and repeated below:
-
ADDITIONAL_ARTIFACTS_REQUIRED=RI_JDK
-
ADDITIONAL_ARTIFACTS_REQUIRED=INSTALLER
-
ADDITIONAL_ARTIFACTS_REQUIRED=TEST_IMAGES,DEBUG_IMAGES,JRE
We will add a table to this issue to outline the expected behaviour, depending on the parameters being used/set.
Adding this table (WIP) for the purposes of outlining various scenarios and listing the expected behaviour or potential 'gotchas' for those scenarios. This can later be added as part of detailed documentation reference. Will keep fleshing this out, and noting that we may add 'constraints' around what is allowable to list in the ADDITIONAL_ARTIFACTS_REQUIRED at the same time for a particular run.
| ADDITIONAL_ARTIFACTS_REQUIRED | JDK_IMPL | SDK_RESOURCE | CUSTOMIZED_SDK_URL | Additional notes |
|---|---|---|---|---|
| RI_JDK | openj9 | nightly | 2 entries: TEST JDK, RI_JDK | Pull TEST JDK from artifactory, pull RI_JDK from server needing CUSTOMIZED_SDK_URL_CREDENTIAL_ID |
| RI_JDK | openj9 | customized | 2 entries: TEST JDK, RI_JDK | will 2 separate CUSTOMIZED_SDK_URL_CREDENTIAL_IDs ever be needed? For now, we say 'not supported' |
| RI_JDK | openj9 | upstream | 1 entry: RI_JDK | need to supply UPSTREAM_JOB_NAME & ID where TEST JDK is fetched from, |
| RI_JDK | hotspot (temurin) | nightly | 1 entry: RI_JDK | Pull TEST JDK from Adoptium API, pull RI_JDK from CUSTOMIZED_SDK_URL |
| RI_JDK | hotspot (temurin) | customized | 2 entries: TEST JDK, RI_JDK | |
| RI_JDK | hotspot (temurin) | upstream | 1 entry: RI_JDK | |
| INSTALLER | openj9 | customized | 2 entries: TEST JDK, INSTALLER | |
| INSTALLER | hotspot | customized | 2 entries: TEST JDK, INSTALLER | |
| TEST_IMAGES,DEBUG_IMAGES | openj9 | customized | 1 entry: TEST JDK or 3 entries: TEST JDK, TEST IMAGE, DEBUG IMAGE | if 1 entry in CUSTOMIZED_SDK_RESOURCE, the script looks for TEST IMAGE and DEBUG images at the same location |
| TEST_IMAGES,DEBUG_IMAGES | hotspot | customized | 1 entry: TEST JDK or 3 entries: TEST JDK, TEST IMAGE, DEBUG IMAGE | if 1 entry in CUSTOMIZED_SDK_RESOURCE, the script looks for TEST IMAGE and DEBUG images at the same location |
RE: https://github.com/adoptium/aqa-tests/issues/4350#issuecomment-1453817503
For the combination of openj9 + nightly (first row in the table), there is an issue - 'nightly' links are openj9 artifactory, which requires that NO credentials be supplied via CUSTOMIZED_SDK_URL_CREDENTIAL_ID. However, RI JDK will be pulled from internal artifactory - which will need the credentials supplied via CUSTOMIZED_SDK_URL_CREDENTIAL_ID. So, this combination may not work, at least for Openj9.
Ya, let's focus on the SDK_RESOURCE=customized case, as it is likely most relevant. :)