Fix: multiarch build by using crosscompilation

[ykulazhenkov]

What this PR does / why we need it:

Use quay.io/centos/centos:stream9 with the –platform=$BUILDPLATFORM flag,
in this case the image is pulled for the builder host's current architecture.
The BUILDOS and BUILDARCH args are used to download the right go binary for
the build platform.
Cross-compilation occurs in the builder image using TARGETOS and TARGETARCH build arguments to determine the target OS/arch.
These args are set automatically by the multiarch-build process (with docker buildx).
The final container image (registry.access.redhat.com/ubi9/ubi-minimal) is pulled for the correct target architecture, such as amd64 or arm64.

This update fixes support for multiarch builds and speeds up image building, as cross-compilation is faster than compiling on a non-native platform.

Special notes for your reviewer:

Fixes support for multiarch builds added in #307

Multiarch build was broken by #319

Release note:

NONE

[kubevirt-bot]

Hi @ykulazhenkov. Thanks for your PR.

I'm waiting for a k8snetworkplumbingwg member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ykulazhenkov]

@phoracek @SchSeba please take a look on this one

[ykulazhenkov]

Additional context is in this message
#260 (comment)

Example of the job with the code from this PR:
https://github.com/ykulazhenkov/ovs-cni/actions/runs/12008233711/job/33470460458
And artifacts
https://github.com/ykulazhenkov/ovs-cni/pkgs/container/ovs-cni-plugin/311494909?tag=v0.101.0

[ykulazhenkov]

no need to set this anymore. Default for the goarch= build-arg is empty string.

[oshoval]

Nice thanks

[oshoval]

go ver is hardcoded here instead taking from go.mod
i believe we can live with it, just raising for awareness in case you think otherwsie

[ykulazhenkov]

I think it is totally acceptable (and even beneficial) to use a newer version of Golang to build the binary. The 1.23 tag will provide us with the latest patch release of 1.23, including all fixes to known CVEs. When Go 1.24 is released, we can update the builder image to the latest version but keep 1.22 in the go.mod file. This approach allows us to be flexible about the compiler version (for downstream consumers who rebuild the image), while the “official” image build always uses a “fresh” version.

[oshoval]

It requires changing on more than one place, which isnt what we strive to do usually,
only rarely we need a different compiler than a language level imho

[ykulazhenkov]

Ok, let's use go.mod if this is standard practice in kubevirt-related projects. I updated PR to rollback to explicit go download.

[oshoval]

Awesome thank you

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: oshoval, ykulazhenkov
Once this PR has been reviewed and has the lgtm label, please assign alonakaplan for approval. For more information see the Kubernetes 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

[oshoval]

curious, why we need this suddenly ?

[ykulazhenkov]

First, we copy go.mod and go.sum to download dependencies explicitly (go mod download), then we copy other code files. This optimizes image rebuilds when only source code changes, allowing Docker to use cached dependencies.
This construction is employed to prevent re-downloading the dependencies whenever possible.
This is pretty common practice. For example, kubebuilder will generate Dockerfile that use such optimization https://github.com/kubernetes-sigs/kubebuilder/blob/cbc6e383c342f1337ab37ee4aa0755957a01f9c7/pkg/plugins/golang/v4/scaffolds/internal/templates/dockerfile.go#L46

[ashokpariya0]

@ykulazhenkov We should update the GOARCH ?= amd64 line (as seen in this Makefile) to:
GOARCH ?= $(shell uname -m | sed 's/x86_64/amd64/')
This change will dynamically set GOARCH based on the host architecture, converting x86_64 to amd64 as needed.

@oshoval changes look good to me, assuming the idea is to provide multiplatform support only through GitHub Actions, exclusively for the Docker container runtime, and not through make commands or for the Podman container runtime.

[oshoval]

@oshoval changes look good to me, assuming the idea is to provide multiplatform support only through GitHub Actions, exclusively for the Docker container runtime, and not through make commands or for the Podman container runtime.

thanks

at the end we will do need also images that are multi platform though isnt it? (as the issue / PRs you work on)
it is fine to do so in steps, as long as those steps can co exists

[ashokpariya0]

@oshoval changes look good to me, assuming the idea is to provide multiplatform support only through GitHub Actions, exclusively for the Docker container runtime, and not through make commands or for the Podman container runtime.

thanks

at the end we will do need also images that are multi platform though isnt it? (as the issue / PRs you work on) it is fine to do so in steps, as long as those steps can co exists

Yes, we can consider adding multiplatform support using a Makefile(using make commands) for both Docker and Podman in the future. This would allow us to build images on our local machine, in a specific environment, or within any CI system, giving us more control over the build process and environment.
For Podman, there are no additional dependencies required to build multiplatform images, while for Docker, we would need the docker buildx tool.

[ykulazhenkov]

We should update the GOARCH ?= amd64 line (as seen in this Makefile) to:
GOARCH ?= $(shell uname -m | sed 's/x86_64/amd64/')
This change will dynamically set GOARCH based on the host architecture, converting x86_64 to amd64 as needed.

done