feat: allow customizable target arch/platform on make build command

[this-is-tobi]

Summary

This PR fix arm64 build.

Note: cf. https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope.

Ticket Link

Fixes #359.

Release Note

support arm64 builds/binaries

[stafot]

@this-is-tobi This proposal LGTM, although I slightly prefer the way it is done in other mattermost repos.

1. We used docker/setup-buildx-action instead of qemu
2. Built multiarach binaries as seperate make command make binaries f.e /~https://github.com/mattermost/elrond/blob/main/Makefile#L57-L96

Are you able to refactor this PR likewise?

[stafot]

Minor. Let's change the release note as it is not a bug but an enhancement to support multiarch. f.e Support arm64 builds/binaries

[this-is-tobi]

Hi @stafot, thanks for the comment !

I may try a refactor as you mentioned but it raises 2 questions for me :

• I always use both docker/setup-buildx-action and docker/setup-qemu-action to have a diverse range of target emulations (including but not limited to arm64) as suggested in the docker documentation.
• In the Elrond example you sent, we can see at line 68 that the build command uses a hard-coded GOARCH=amd64 parameter and this is the command used in the Dockerfile so for me this repository is also concerned with bad binary architecture inside the docker image because the image (even if the target platform is set to linux/arm64) will always build and include binaries for amd64.

A proposal for this PR would be :

1. Create a dedicated binaries command in the makefile to be able to publish different binaries (perhaps you'd like me to work on a deeper refactor of the publishing script to achieve harmonization with Elrond ? But I'd rather do that in another PR and would probably need more information on the publishing system/process).
2. Let the Dockerfile define the right OS and ARCH to build the right binary of the current target image (i.e linux/amd64 and linux/arm64) with the current build command proposal.

Edit: Another option would be to use the new make binaries command inside the Dockerfile and copy only the correct binary in the second stage, but this would take longer to build the binaries and use only one at the end.

Let me know what you think.

[stafot]

@this-is-tobi You are correct about

In the Elrond example you sent, we can see at line 68 that the build command uses a hard-coded GOARCH=amd64 parameter and this is the command used in the Dockerfile so for me this repository is also concerned with bad binary architecture inside the docker image because the image (even if the target platform is set to linux/arm64) will always build and include binaries for amd64.
A similar but correct approach is here -> /~https://github.com/mattermost/mattermost-cloud-database-factory/blob/master/build/Dockerfile#L9

For now I am ok with your current PR (Option 2) If you are willing in a future PR you can proceed with Option 1.

[Silvest89]

What's the status of this @stafot ?

[this-is-tobi]

Hi,

I've been trying to investigate a deeper refactor to follow the Mattermost package release system but unfortunately I think I need more information about your release process (do you trigger the release manually or by pushing into the main branch? do you want to put the binaries in the github release? etc...). Also, I'm just starting to develop with golang and probably need to dive into golang's release options (flags, etc...).
I hope we can merge this PR as a workaround until a closer look at the publishing process can be done properly.

Finally, merging this PR will make the mattermost-operator image multi-arch but there is still the same problem for the mattermost server image and when I look at the repo I don't see anything that matches the publishing system of the production image (cf. this issue) as if it had been built from another source and I can't find any information about it.

[fmartingr]

I think we do not need qemu a this stage since we don't use CGO in the operator (neither in the server IIRC) so we can rely on cross-compilation directly, letting the go compiler build the binaries for each arch. As @stafot suggested using buildx should be enough.

Since this PR specifies arm64, cross-compilation should be enough for that and the default amd64 binaries.

[this-is-tobi]

QEMU action removed @stafot @fmartingr

[fmartingr]

This LGTM, it allows users to compile to their preferred platform by cloning the repository.

We would need to talk if we want to push/support multi-arch images ourselves, I'll leave that to @mattermost/cloud to decide.

[gabrieljackson]

This is great! Thanks for the contribution @this-is-tobi.

[this-is-tobi]

This LGTM, it allows users to compile to their preferred platform by cloning the repository.

We would need to talk if we want to push/support multi-arch images ourselves, I'll leave that to @mattermost/cloud to decide.

@fmartingr I guess it will be done by the CI/CD :

1. The cd.yml pipeline will trigger the makefile with buildx-image command
2. The makefile will trigger the build_image.sh script
3. The build_image.sh will trigger images build with args "--platform" "linux/amd64,linux/arm64" "--push"
4. The dockerfile will trigger the makefile with build command using architecture auto-detection passed as args, see:

• /~https://github.com/mattermost/mattermost-operator/blob/master/Dockerfile#L7
• https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope

5. Finally the build command will build to the appropriate architecture

We've come full circle, even if it's not the easiest
Wait and see 🌸