Multi-platform/architecture docker image support

[kawerewagaba]

Is your feature request related to a problem? Please describe.
Setting up a local environment to build and test CHT 4.x (and 3.x) applications. I get this warning when i run docker compose up: cht-upgrade-service The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested. The containers seem to be running, but the app is broken as shown below:

I also noticed a couple errors, not sure they're related to the platform issue:

Describe the solution you'd like
Images that support both linux/amd64 and linux/arm64/v8 platforms.

Describe alternatives you've considered
Locally rebuilding the images and running the containers - for development - will see how this turns out, but seems to be a viable option. I should also point out that I'm closely following this discussion on the forum.

Additional context
Chip: Apple M2 Pro
macOS: Ventura 13.0

Docker desktop screenshot

[Hareet]

@kawerewagaba Nice issue :)
Right now, GitHub Actions doesn't support arm64 runners: actions/runner#805 (comment)

It's in their plan for q4 2023, so hopefully we can wait it out.

actions/runner-images#2187
actions/runner-images#5631

We build the images in CI, so I think its possible that we self-host a GH Action runner as seen from this post: https://aws.amazon.com/blogs/compute/building-arm64-applications-on-aws-graviton2-using-the-aws-cdk-and-self-hosted-runners-for-github-actions/

But our repository would need to heed this warning from the link above:

GitHub recommends only utilizing self-hosted runners with private repositories. 
Allowing self-hosted runners on public repositories and allowing workflows on public forks 
introduces a significant security risk.

tl;dr: I don't know how soon this will happen. I'd love arm64 4.x images, but we'd want to replicate CI tests and ensure the artifact hasn't changed. I'm not of the biggest fan of building it locally and distributing the arm64 images in case any dependency changes but that is something we could consider.

[dianabarsan]

Thanks a lot for reporting @kawerewagaba

While we wait for GH support, maybe we could consider a manual step in our release process to build these images for other common architectures.

I'm not sure how feasible this is, but if we're going to get support out of the box through GitHub actions, I'm tempted to not over-engineer the workaround.
Appreciate any inputs @garethbowen @craig-landry @Reagan

[garethbowen]

Manual makes sense to me assuming it's only final releases. It should only be a few builds assuming GH sticks to their roadmap.