Optimise `multiarch` sanity check duration

[lemeurherve]

What feature do you want to see added?

The multiarch stage (a sanity check one) is the longest one (taking about 45 minutes) and currently builds images for every architectures, even if the current agent architecture images are already built in other stages.

Other stages building a list of targets are calling make build-<target> or make test-<target> which are using make list, returning only targets for the current agent architecture (amd64):

docker/Jenkinsfile

Lines 135 to 146 in 5a8f228

	stage("Build linux-${imageToBuild}") {
	infra.withDockerCredentials {
	sh "make build-${imageToBuild}"
	}
	}
	stage("Test linux-${imageToBuild}") {
	sh 'make prepare-test'
	try {
	infra.withDockerCredentials {
	sh "make test-${imageToBuild}"
	}

docker/Makefile

Lines 78 to 79 in 5a8f228

	list: check-reqs
	@set -x; make --silent show | jq -r '.target | path(.. | select(.platforms[] | contains("linux/$(ARCH)"))?) | add'

This stage should be optimised to build only build architectures not already built in those other stages so it takes less time, to reduce the overall build duration.

Current state

List of targets and architectures built in the multiarch stage:

alpine_jdk17 (amd64)
alpine_jdk21 (amd64, arm64)
debian-slim_jdk17 (amd64)
debian-slim_jdk21 (amd64, arm64)
debian_jdk17 (amd64, arm64, s390x, ppc64le)
debian_jdk21 (amd64, arm64, s390x, ppc64le) 
rhel_ubi9_jdk17 (amd64, arm64, ppc64le)
rhel_ubi9_jdk21 (amd64, arm64, ppc64le)

Total: 20 distinct images.

Overall build duration: 47 min

https://ci.jenkins.io/job/Packaging/job/docker/job/master/13084:

Upstream changes

No response

Are you interested in contributing this feature?

Yes

[lemeurherve]

Gains from #2155 can be even more increased by building only the default JDK in multiarch, as building one JDK is enough to validate a proper build on those architectures.

[dduportal]

as building one JDK is enough to validate a proper build on those architectures.

This is not true. JDKs support on different CPU architecture has been notoriously heterogeneous. On each "quarterly" patch upgrade, we've seen many different result in the 3 weeks following the patch.
We don't want to deliver a Jenkins container image on architectures where the initial JDK is buggy.

[dduportal]

even if the current agent architecture images are already built in other stages.

Adding complexity to the makefile without solving the cache issue seems a bad idea TBH.

• Why is the "already" built image not cached? It should take less than 5s for Docker + BuildX to detect that nothing changed and reusing the already built cache. That is the key.
• What is the reason for building ALL architectures on the same agent?
  • Could there be any resource contention in the agent used for multi-architecture (not even mentioning the qemu emulation)
  • Could we use native platform for at least amd64 and arm64 on parallel agents (like the windows OSes)?

[dduportal]

#2155 Sounds like a promising first step 👏

[lemeurherve]

even if the current agent architecture images are already built in other stages.

Adding complexity to the makefile without solving the cache issue seems a bad idea TBH.

• Why is the "already" built image not cached? It should take less than 5s for Docker + BuildX to detect that nothing changed and reusing the already built cache. That is the key.

• What is the reason for building ALL architectures on the same agent?

  • Could there be any resource contention in the agent used for multi-architecture (not even mentioning the qemu emulation)
  • Could we use native platform for at least amd64 and arm64 on parallel agents (like the windows OSes)?

I can only trace this separate multiarch build back to #1198