Add arm multi platform support

[dharmendra-byte]

Rationale for Multi-Platform Support

1. Cause of Incompatibility:
The previous build process created images only for the host architecture (implicitly linux/amd64). This caused the Meshery Operator to fail with an "Exec format error" when run on modern ARM-based hardware (e.g., Apple Silicon or cloud instances like AWS Graviton). The single-architecture image was incompatible with the multi-architecture runtime environment.

2. Changes to Overcome Incompatibility:
To resolve this, I implemented a true multi-platform build strategy:

• Docker Buildx Integration: Updated the GitHub Actions workflow to leverage docker buildx to build and push manifest lists for two architectures: linux/amd64 and linux/arm64.
• Dynamic Dockerfile: Updated the Dockerfile to use the built-in variables $BUILDPLATFORM and $TARGETPLATFORM. This allows the build process to dynamically compile the application for the correct target architecture, eliminating the need for hardcoding.
• Backward Compatibility: Added default values for local development using regular docker build.
  Fixes Add support for ARM with a multi platform workflow #355

[dharmendra-byte]

@leecalcote Could you review this PR?

[leecalcote]

Squash your commits. There are entirely too many.

Explain how your changes make the embedded sqlite ARM compatible.

[leecalcote]

Signoff on your commits.

[leecalcote]

List the LLM model and version that you're using.

[dharmendra-byte]

Squash your commits. There are entirely too many.

Explain how your changes make the embedded sqlite ARM compatible.

This change does not touch sqlite. the Meshery Operator doesn’t embed or link sqlite; its a controller binary built statically with CGO disabled and packaged on distroless. I only enabled multi-arch (linux/amd64, linux/arm64) builds via docker buildx. So ARM compatibility here is independent of sqlite

[dharmendra-byte]

Done

[lekaf974]

small comment LGTM otherwise

[dharmendra-byte]

@leecalcote pls review

[leecalcote]

Where have you explained the cause of the incompatibility and the changes to overcome that cause?

[dharmendra-byte]

Where have you explained the cause of the incompatibility and the changes to overcome that cause?

@leecalcote I have updated the main PR description to include a structured explanation detailing the cause of the incompatibility and the changes to overcome it using Docker Buildx and dynamic platform variables. Please let me know if this clarifies things sufficiently for you!

[leecalcote]

@ProgrammingPirates you're right about sqlite. When I first took a quick look, I thought this PR was on meshery/meshery.

[leecalcote]

Join tomorrow's dev meeting. Add this PR as an agenda item, yeah?

[leecalcote]

@ProgrammingPirates drop your agenda item here -https://docs.google.com/document/d/15IEwtTxPOkQXN2r_1LzGXuAv2mIUlmbdtmxpyxXF-KI/edit?tab=t.0

[leecalcote]

@ProgrammingPirates, please reuse (copy/paste) our multi-platform.yml workflow (used broadly across Meshery repos) for ARM support - https://github.com/meshery-extensions/meshery-istio/blob/master/.github/workflows/multi-platform.yml

[Rajesh-Nagarajan-11]

Thank you for your contribution! 🎉

If this work is completed, this would be a great item to add to the weekly Meshery Development Meeting agenda.
Please update the meeting document, attend the meeting, and present your progress.

Meeting Details

• Date: December 03
• Time: 8:30 PM IST
• Join Link: https://meet.layer5.io/meshery

[leecalcote]

@ProgrammingPirates are you going to address my last two comments?

[naman79820]

May i take it over?

[Saanvim11]

Hi @leecalcote and @lekaf974 , I’m interested in working on this issue/PR. If it’s currently stalled or not actively being worked on, I’d be happy to help finish the remaining tasks (workflow reuse + squash commits). Please let me know if I can take this over or contribute alongside

[Bhavika42]

Hi @leecalcote I noticed this PR is currently stalled and that the remaining requested change is to reuse Meshery’s existing multi-platform.yml workflow used across Meshery repositories.
I’m interested in helping if additional support is needed. I can review the referenced workflow, compare it with the current meshery-operator build/release workflow, and prepare a small follow-up PR or assist with the required changes after maintainer confirmation.

Since a couple of contributors have already expressed interest in taking this over, I’ll wait for maintainer guidance before starting work to avoid duplicate effort.

[leecalcote]

@Bhavika42, yes, please do offer review. 👍

[lekaf974]

I think this can be improved a little

[Bhavika42]

Thanks @leecalcote, I’ll review the current workflow changes against the referenced multi-platform.yml workflow and look into the remaining requested improvements.

[Bhavika42]

One thing I noticed while comparing the changes with the referenced multi-platform.yml workflow is that the multi-platform build logic still seems to be implemented directly inside build-and-release.yml.

It might be cleaner and easier to maintain if the ARM/multi-platform build steps reuse the shared workflow structure already used across Meshery repositories, rather than duplicating the build/push logic here.

[leecalcote]

Thanks for pushing on ARM support - Apple Silicon and Graviton compatibility matters and your buildx approach is the right shape.

We are honoring this in Workstream 8 (CI revamp), where instead of a bespoke buildx block we reuse meshery's shared multi-platform.yml so the operator inherits the same maintained multi-arch pipeline as the rest of the org, with every action pinned to a commit SHA rather than a moving tag. Your earlier points about squashed and signed-off commits still apply for any direct merge.

Net result: the multi-arch outcome you want lands through WS-8, which will supersede this PR. Thank you for raising it.