[2.13.x] - Update 2.13 to use the new container images

[cescoffier]

Update the Quarkus images to multi-archs variants

• the builder images are now: quarkusubi-quarkus-graalvmce-builder-image and quarkusubi-quarkus-mandrel-builder-image. Both at multi-archs (AMD64 and ARM64).
• the s2i images are now: quarkusubi-quarkus-native-binary-s2i:2.0 and quarkusubi-quarkus-graalvmce-s2i
• the base images are now: quarkusquarkus-micro-image:2.0 and quarkusquarkus-distroless-image:2.0

[rsvoboda]

There is #30829 concern for S2I with the new images.

Can you check it @cescoffier pls?

[gsmet]

@rsvoboda AFAICS, #30829 has been addressed. Should we merge?

[rsvoboda]

In general we are moving to the new generation of builder images in 2.13 and I think we should be ok with that. But it's better to be safe, so I will check with my team mates.

[gsmet]

Let me fix the conflicts.

[gsmet]

Conflicts fixed.

[rsvoboda]

There are also 2 other places that are using 1.14 version

integration-tests/maven/src/test/resources-filtered/projects/codegen-config-factory/app/src/main/docker/Dockerfile.jvm:FROM registry.access.redhat.com/ubi8/openjdk-11:1.14
integration-tests/maven/src/test/resources-filtered/projects/codegen-config-factory/app/src/main/docker/Dockerfile.legacy-jar:FROM registry.access.redhat.com/ubi8/openjdk-11:1.14

I think all the versions of openjdk image should be synced (even though these are just tests and main is also using older 1.14)

[rsvoboda]

Shouldn't this be openjdk-11:1.15 like in 2 other cases?

[rsvoboda]

Shouldn't this be openjdk-17:1.15 like in 2 other cases?

[gsmet]

It should and that's concerning as it looks like the previous backport didn't change them. I need to have a closer look.

[gsmet]

It looks like we are using a floating tag for these 2 in main so that's why they weren't updated in main and thus not backported.
I'll go fix that in an additional commit.

[quarkus-bot]

Failing Jobs - Building 8aca0ac

Status	Name	Step	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11	Build	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.AvroDevModeTest.main line 15 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

---

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.ConditionalDependenciesTest.scenarioTwo line 147 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting path:

✖ io.quarkus.gradle.devmode.MultiSourceProjectDevModeTest.main line 22 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[rsvoboda]

Thanks for update @gsmet. I spoke with people in the team and we have no objections.