Add multi-arch native image and Mandrel image push steps

[galderz]

This should close #83, but I think we'll only know if it really works once integrated and we try to push the images. @cescoffier?

/cc @zakkak Clement had suggested that maybe push images script should become a jbang script. WDYT?

[zakkak]

We should definitely find a better way to figure out the tags, ideally fetching them from

quarkus-images/.github/mandrel-images.yaml

Line 4 in 5407633

versions:

If jbang is the preferred way I am OK with that. After all I never had to touch "push-images" before, so I would prefer the people actually maintaining it to decide what they prefer.

[galderz]

When I first discussed this with @cescoffier, I agreed with your statement: let's make this a jbang script and consume the versions in yaml, but I don't think it'll really solve the little hardcoding done in the bash script.

Put it this way: none of the image versions that need to be created (e.g. mandrel 22.1.0.0.Final-java17 or graalvm 22.0.0-java17) are part of the versions that you pass in in the yaml. The versions that you pass in are the ones you build the traditional way (same for build and push) and then you have these extra overarching versions that are only used by push and created and pushed differently (e.g. docker manifest create... and docker manifest push).

So, I'm currently leaning towards keeping things as they are in the PR. One thing that complicates making wide ranging changes in the push side is that there's no real way to test it until you get the GH action to kick in and see if it works as expected. Note that I actually tested something very similar to this in my own repo's main branch and a custom GH action. That's how I ended up pushing multi-arch images to my own fork, see here.

[galderz]

It's true as well that you could enhance the yaml to somehow add the multi arch tags (something akin to what happens with tags) and then have some kind of way of saying that this multi-arch tag is built out of these other tags. E.g.

multi-arch-tags:
  - id: 22.1-java17
    versions:
    - 22.1-java17-amd64
    - 22.1-java17-arm64
  - id: 22.1.0-java17
    versions:
    - 22.1.0-java17-amd64
    - 22.1.0-java17-arm64

[edeandrea]

@galderz I'm happy to test this with the Quarkus superheroes once there are multi-arch images available somewhere. As I mentioned on #83 I already have the scaffolding & wiring in place. All I need are quay.io/quarkus/ubi-quarkus-mandrel and quay.io/quarkus/quarkus-micro-image images that have both amd64 & arm64 platforms available.

[galderz]

@edeandrea No work has been done here to add multi arch support for quarkus-micro-image. This PR and #195 focused on adding multi-arch support for GraalVM and Mandrel container images.

[edeandrea]

Thanks @galderz . Does that mean in the interim I'd have to switch back to the Dockerfile that uses FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5?

[galderz]

Thanks @galderz . Does that mean in the interim I'd have to switch back to the Dockerfile that uses FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5?

Switch what?

[edeandrea]

A Dockerfile that uses the quarkus-micro-image as it's base image (like https://github.com/quarkusio/quarkus-super-heroes/blob/main/rest-villains/src/main/docker/Dockerfile.native#L20)

[galderz]

Hmmmm, yeah, I guess you could change FROM to registry.access.redhat.com/ubi8/ubi-minimal:8.5 and then do things manually yourself if needed. I don't know anything about quarkus-micro-image TBH.

[edeandrea]

I'll do that once your work on the ubi-mandrel image is done and those images are available.

[galderz]

This work won't be integrated as is. The partial work in master is not fully working as expected. An effort is ongoing to provide a better solution.