Determine naming conventions for non-dockerhub container pushes

[sxa]

This is a list of naming conventions we have in the different repositories which we use which can be used as input to what we do in the future, particularly for an alternate repository for the end-user temurin images.

While we will likely leave the dockerhub ones as-is, since we are now aiming to push to alternate repositories we should look at the naming conventions in use and select which ones to use for the test-container publishing (Will likely be moved to adoptium_test_image instead of test-containers on ghcr to avoid confusion and align with the build image naming).

The expectation is that all of the images pushed to locations other than dockerhub will be verifiable using sigstore.

Naming conventions already in use:

• dockerhub official images:
  • eclipse-temurin:8u472-b08-jdk-ubi9-minimal, 8-jdk-ubi9-minimal, 8-jdk, 8
• adoptopenjdk official images
  • Similar to the above - no longer maintained e.g. adoptopenjdk/8u292-b10-jre-openj9-0.26.0
• adoptopenjdk standard (updated by openjdk_build_docker_multiarch)
  • Separate per version e.g. adoptopenjdk/openjdk8:aarch64-ubi-jdk8u292-b10-slim or jdk8u292-b10-ubi-slim or ubi-slim
• build images (under same adoptopenjdk repo as the last one - updated by centos7_docker_image_updater)
  • adoptopenjdk/centos7_build_image:linux-amd64 or just adoptopenjdk/centos7_build_image
• GHCR test-containers (Updated by test_image_updater
  • ghcr.io/adoptium/test-containers:ubi10-arm64 or ghcr.io/adoptium/test-containers:ubi10
• GHCR build images - updated by build_image_updater)
  • ghcr.io/adoptium/adoptium_build_image:centos7_linux-arm64 or centos7

[sxa]

FYI @AdamBrousseau @mahdipub @smlambert @jiekang and anyone else who wants to voice an opinion on the topic ;-)

[smlambert]

Thanks @sxa !

From the test perspective, we will want images for as many arch/platform/os as possible, with a naming convention that makes it easy to find and map to our tags (hw.arch.xxxx and sw.os.yyyy and we will add code that randomizes selection of variants of yyyy).

We also want to utilize this approach to simplify our external test group. Currently as part of an external test run, we auto-generate the Dockerfile based on the 3rd party application and its dependencies, but we can push these images to ghcr and save time and reduce complexity of the test run.

If we are keeping close to what is already there, then a convention where:

• osvariant values are [ubi10, ubuntu2404, etc]
• arch values are [aarch64, ppc64le, x86-64, etc] - though looks like you are using amd64 for x86-64 and arm64 for aarch64 respectively
• 3rdpartyapp values map to those found in external dir [camel, derby, jacoco, etc]

are combined to push images to adoptium-test-image

• osvariant-arch - [ubi10-x86-64, ubi10-aarch64, ubuntu2404-aarch64, etc]
• osvariant-arch-3rdpartyapp [ubi10-aarch64-derby, etc]