AMZN2 linux and Mandrel dev master images

[Karm]

No description provided.

[Karm]

@jerboaa The dev image is now JDK 26 based:

$ podman run quay.io/quarkus/ubi-quarkus-mandrel-builder-image:dev --version
native-image 26-internal 2026-03-17
OpenJDK Runtime Environment Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk)
OpenJDK 64-Bit Server VM Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk, mixed mode)

It's built on RHEL 8, but with gcc 10 toolchain. The resulting binaries from this Mandrel sdk work fine on UBI8, but they fail on Amazon Linux 2 as its GLIBC is way too old - even older than on UBI8.

Not sure what to do about it if anything. It's likely O.K. as that Amazon Linux 2 is really an old environment.

[jerboaa]

@jerboaa The dev image is now JDK 26 based:

$ podman run quay.io/quarkus/ubi-quarkus-mandrel-builder-image:dev --version
native-image 26-internal 2026-03-17
OpenJDK Runtime Environment Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk)
OpenJDK 64-Bit Server VM Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk, mixed mode)

It's built on RHEL 8, but with gcc 10 toolchain. The resulting binaries from this Mandrel sdk work fine on UBI8, but they fail on Amazon Linux 2 as its GLIBC is way too old - even older than on UBI8.

Not sure what to do about it if anything. It's likely O.K. as that Amazon Linux 2 is really an old environment.

@Karm Do we want JDK 26 based dev images? I'd think JDK 25 images would be in higher demand. Would they still be available?

[jerboaa]

@jerboaa The dev image is now JDK 26 based:

$ podman run quay.io/quarkus/ubi-quarkus-mandrel-builder-image:dev --version
native-image 26-internal 2026-03-17
OpenJDK Runtime Environment Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk)
OpenJDK 64-Bit Server VM Mandrel-26.0.0-dev622e487a68a (build 26-internal-adhoc.tester.jdk, mixed mode)

FWIW, we'd need a better version output than this. At the very least it ought to have 26+N where N is the latest number in the promoted tags of the repo jdk-26+6 for example. Otherwise, we have no idea about the JDK version without needing to look at the release file.

[Karm]

@jerboaa

@Karm Do we want JDK 26 based dev images? I'd think JDK 25 images would be in higher demand. Would they still be available?

The current logic of the automation follows the master and the master is currently JDK 26 based and doesn't work with JDK 25 any more. The last JDK 25 dev image on Quay is jdk-25.0.0_26.

I guess it might be worth it to modify it to follow two build jobs, the master one and the...next one? ea one? In this case 25.0.

FWIW, we'd need a better version output than this.

Yes. Definitely. I need to adjust it here https://github.com/graalvm/mandrel-packaging/blob/master/jenkins/jobs/builds/Constants.groovy#L253 and switch to Temurin when available.

The job does try to download Temurin first and falls back on our own build if there is no Temurin to download:
https://github.com/graalvm/mandrel-packaging/blob/master/jenkins/jobs/builds/Constants.groovy#L37

[jerboaa]

FWIW, we'd need a better version output than this.

Yes. Definitely. I need to adjust it here https://github.com/graalvm/mandrel-packaging/blob/master/jenkins/jobs/builds/Constants.groovy#L253 and switch to Temurin when available.

I'd suggest to only merge this once it's implemented. Otherwise we are bound to sending people off on a wild goose chase...

[zakkak]

I guess it might be worth it to modify it to follow two build jobs, the master one and the...next one? ea one? In this case 25.0.

Sure, the problem is that I don't see how you could automate the detection of whether there is a branched version going through the ramp down and RC phases, as well as what that version might be.