make: add support for building multi-arch image manifest

[vyasgun]

Builds separate images for amd64 and arm64, creates a manifest of the images, and pushes the multiarch
manifest to the registry

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vyasgun
Once this PR has been reviewed and has the lgtm label, please assign evidolob for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gbraad]

This relies on qemu-user-static to provide an emulated container build. Is this approach we want? On other crc projects we use native runners for the container assets. This is why images/Dockerfile does a plain make build, as that means the arch specification controls the target. runs-on with an upload and aggregation job, can solve this: https://gist.github.com/gbraad/f8a46c5958d158707d18a333a414a900

[gbraad]

Why is this not:

	${CONTAINER_RUNTIME} build [--arch amd64|--platform linux/amd64] -t $(IMAGE)-amd64 -f images/Dockerfile .
	${CONTAINER_RUNTIME} build [--arch arm64|--platform linux/arm64] -t $(IMAGE)-arm64 -f images/Dockerfile .

to be more consistent in the way this is written. I think you might experience issues between steps that the image downloaded is architecture specific, and therefore needs to be removed to be correctly handled.

As this seems to assume, it was build from an Arm-based machine.

Note: this will also build for one of the architectures using emulation, as the images/Dockerfile performs a RUN make. This can be slow and not according to what we normally do for 'secondary architectures' (only allow native builds or cross compilation).

[gbraad]

Maybe try if a make cross and create for --arch --platform and a cp -a would work? This might be a way to actually prevent it to 'run' the image under virtualization/emulation.

[gbraad]

I still believe this is the wrong approach. This could work for development, but not for release.

For a release, the process can run on a native runner; perform a native build with the Dockerfile, aggregate files in a job and publish the manifest.

[cfergeau]

ideally we would be building on native runners/… May not be that hard using https://github.com/gbraad-dotfiles/upstream/blob/main/.github/workflows/reusable-build-and-push-containers.yml#L43-L76

However, the container image we use at the moment hasn’t been updated in 2 years, so (in my opinion) any automation is an improvement, even if it involves qemu-user-aarch64.

We can also do this in multiple steps, do something that works, and then remove the use of the emulation code. Or delay this by a few days, as if we can finish crc-org/snc#1052 then the container image is no longer that useful.

[gbraad]

Since this pushes to a public endpoint, this is a release process.
This solution does not get my preference as it involves emulation.

[gbraad]

For now; let's focus on crc-org/snc#1052 as that can remove the need for this container image. There is still a podman cp that pulls the executable out of this image; that has to become an RPM or so.

Note: quay.io/crcont/gvisor-tap-vsock:${TAG} is very specific for the CRC/SNC usecase and should not belong in the upstream repo.

[Copilot]

Pull Request Overview

This PR introduces multiarch support by building separate images for amd64 and arm64, creating a manifest for these images, and pushing the manifest to the registry.

• Adds an IMAGE variable and new build commands for both architectures.
• Implements manifest creation, cleanup, and push steps.

[cfergeau]

With crc-org/snc#1052 merged, we no longer need this.