EPIC: Provide Eclipse Temurin images on multiple registries

[jiekang]

It would be nice to have Eclipse Temurin container images available on multiple registries, including DockerHub, ghcr.io, and perhaps quay.io. This would give people more choice for where they pull images from, and more resilience and availability.

[sxa]

Related (In terms of other places we're pushing to non-docker registries):

• Can we create verifiable checksums for our dockerBuild images? infrastructure#2734
• Request adoptopenjdk & Temurin container build images be published to alternate hosting site infrastructure#3830 (Was used to cover the internal images used for build only)
• Trying to pull build images from ghcr.io with tags is not working when credentials required ci-jenkins-pipelines#1199 (For private build images)
• EPIC: New Machine requirement: Windows dockerBuild containers infrastructure#3286 (Windows docker build images)

Noting also that we have the existing https://ci.adoptium.net/job/openjdk_build_docker_multiarch/ which is still pushing some of the older versions up to a non-official registry on dockerhub although that should be considered deprecated (and will be considered even more deprected if we push elsewhere regularly with all supported JDK versions)

[sxa]

Noting that such pushes will not just be part of the releases pipeilnes as we will then be responsible (as with the non-official pushes mentioned in my previous comment) for ensuring that CVEs are appropriately managed, which will need appropriate policies in place.

[sxa]

Todo:

• Decide on the naming convention that end users will see in their podman pull commands. Need to ensure that any visible UI isn't "messy" with
• Set up a job comparable to openjdk_build_docker_multiarch which will push to an alternate repository - likely ghcr.io which we have precedent for
• Decide on a schedule for OS security updates, and whether to rebuild from scratch each time or "pull, update, push".
• Ideally have cosign in place as per the first bullet point of my first comment on this issue, or provide some other verification capability. (Noting that cosign is currently making the repositories look at bit messy)

Anything else?

[jiekang]

The need to respin for CVEs is going to generate a considerable amount of work without proper automation... and probably even with proper automation.

The checklist you've written makes sense to me; thanks Stewart.