Skip to content

Conversation

@lemeurherve
Copy link
Member

@lemeurherve lemeurherve commented Dec 24, 2025

This PR adds buildarch-% and listarch-% targets to the Makefile, allowing then to build in parallel images of architectures not already built in other stages, to improve overall build duration.

Before, multiarch stage was building the following targets and architectures:

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 in one stage.

With this change, only the following targets and architectures are built in multiarch stages:

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

Total: 12 distinct images.

  • 6 in arm64 stage
  • 2 in s390x stage
  • 4 in ppc64le stage

Ref:

Testing done

List of targets per architecture
$ make listarch-amd64
alpine_jdk17
alpine_jdk21
debian-slim_jdk17
debian-slim_jdk21
debian_jdk17
debian_jdk21
rhel_ubi9_jdk17
rhel_ubi9_jdk21

$ make listarch-arm64
alpine_jdk21
debian-slim_jdk21
debian_jdk17
debian_jdk21
rhel_ubi9_jdk17
rhel_ubi9_jdk21

$ make listarch-s390x
debian_jdk17
debian_jdk21

$ make listarch-ppc64le
debian_jdk17
debian_jdk21
rhel_ubi9_jdk17
rhel_ubi9_jdk21
CI build before: Image
CI build after (outdated, see below): image

With f453ad3, the arm64 stage went from 25 minutes to 2 minutes 27 seconds 🚀

Before f453ad3: image
After: image

The bottleneck is now (again 😅) the Windows stage*, the overall build duration is decreasing from 47 minutes to 23 minutes on ci.jenkins.io 🎉

I'll open an issue to discuss the split of the publish stage of trusted.ci.jenkins.io into similar parallel stages with one architecture each to reduce its build duration too.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests that demonstrate the feature works or the issue is fixed

@dduportal
Copy link
Contributor

Overall build duration decreased from 47min to 28min on ci.jenkins.io 🥳
👏

@lemeurherve lemeurherve marked this pull request as draft December 25, 2025 16:02
else
@docker buildx create --use --bootstrap --driver docker-container
endif
# There is only an amd64 qemu image
Copy link
Member Author

@lemeurherve lemeurherve Dec 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a replay: https://ci.jenkins.io/job/Packaging/job/docker/view/change-requests/job/PR-2155/9/pipeline-overview/?start-byte=0&selected-node=309#log-309-32

17:06:31  Status: Downloaded newer image for multiarch/qemu-user-static:latest
17:06:33  WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

@lemeurherve
Copy link
Member Author

lemeurherve commented Dec 25, 2025

With f453ad3, the arm64 stage went from 25 minutes to 2 minutes 27 seconds 🚀

Before: image
After: image

The bottleneck is now (again 😅) the Windows stage*, the overall build duration is decreasing from 47 minutes to 23 minutes on ci.jenkins.io 🎉

*: pending completion of jenkinsci/docker-agents#1068 that should decrease its duration.

@lemeurherve lemeurherve requested review from a team and dduportal December 25, 2025 16:42
@lemeurherve
Copy link
Member Author

lemeurherve commented Dec 25, 2025

Last build using s390x permanent agent (from ~7min30s to ~1min 🚀):

image

@lemeurherve lemeurherve merged commit bb0fa3c into jenkinsci:master Dec 26, 2025
11 of 12 checks passed
@lemeurherve lemeurherve deleted the multiarch-optim branch December 26, 2025 16:17
def imageToBuild = i

builds[imageToBuild] = {
nodeWithTimeout('docker') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is now different to the publish build isn't it?

The production build uses https://github.com/lemeurherve/docker/blob/dc9309cbe33f3523f7dae6c8ca4642f1145950c1/Jenkinsfile#L193

So if there's an issue in QEMU emulation we won't catch it on CI. This has happened before...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, only the label was common before, nothing was preventing agent definitions to diverge between ci.jenkins.io and trusted.ci.jenkins.io.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes but QEMU is important that its validated on CI especially for new images

Copy link
Contributor

@lemeurherveCB lemeurherveCB Dec 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about using agents with dedicated architectures for publication on trusted.ci.jenkins.io like the ones used on ci.jenkins.io build introduced with this PR, would that be sufficient to alleviate this potential issue in your opinion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that’s fine as long as the same across both

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants