Update docker build scripts to provide more information to downstream scripts

[smlambert]

Looking for an interim approach while designing a bigger refinement to how we do releases at the AdoptOpenJDK project (potentially trigger/choreograph all activities from a central pipeline or workflow), but in the near term, here is what I would like to accomplish:

• at the end of a successful creation of docker images and manifest file I would like to launch testing on all of the images that were produced

• first cut was to trigger testing from the successful finish of the docker manifest job - I have done this in a naive way, but it is problematic. There is no information about JDK_IMPL, JDK_VERSION of what is being run as part of the manifest job (one would have to inspect the console output at present, which is not optimal for an automated approach).

I have currently made the assumption its always running jdk14 and so launch , since the last many runs were for that JDK_VERSION.

What artifacts or information is available from the docker build scripts that can be used to determine what testing to run?

[smlambert]

@dinogun - can you point me to doc or share a brief overview of the process by which docker image builds are launched, both the nightly scenario and the release week scenario (for the various versions / variants).

[smlambert]

From looking at scripts, I am thinking it may make sense to wrap your existing scripts in a pipeline script that is triggered from the main build pipelines (and subsequently launches testing as a step in the process). Having more info on the current process will be helpful in deciding what is the right next action to take.

[dinogun]

@smlambert Sorry for the late response, the current docker build pipeline is split into two parts

I. openjdk_build_docker_multiarch jenkins job that runs every night and runs through all the valid combinations

• All supported versions - 8, 11, 13 and 14
• VM implementations - HotSpot, OpenJ9
• Packages - JDK, JRE
• Build Types - releases, nightly
• Supported OSes - Alpine, CentOS, ClefOS, Debian, DebianSlim, UBI, UBI-minimal, Ubuntu
• Functionality - Slim and Full
• All valid architectures - aarch64, arm32, ppc64le, s390x, x86_64

One reason to go through the entire set is to make sure we rebuild docker images for any underlying OS updates (for vulnerability updates). Note that these builds only happen if

1. A docker image for that build does not exist
2. A newer base OS docker image is available
3. A newer build tarball is available

II. We then kick off the openjdk_build_docker_manifest job to regenerate all the tags to point to the newer build if any. The docker_manifest job goes through all of the valid combinations as above as well.

[dinogun]

There are two ways to test the docker images.

1. Break up the docker image build process into a more granular combination that gets triggered when a openjdk build completes successfully.
   • This might miss any updates to base docker images.
   • Needs a lot of refactoring of the docker build pipeline.
2. Have a separate test job that runs through all valid combinations similar to what the docker build job does.

I would suggest we go with 2. for now, until we can figure out more details on the testing at which point we can re-evaluate. The other advantage with 2. is that we can share the same config files and scripts as the docker image process to kick off testing.

Also one other point to mention, we have a "test" script in the docker repo, that currently just runs java -version test after the build/manifest job completes.

[grzesuav]

@dinogun I believe most of the scripts are parameterized (takes arguments etc), so maybe allowing granulated build (like only jdk13 or particular distribution) is direction to go ?