fix: Move docker builds to native platforms

[clintjedwards]

The current Docker builds are taking an excessively long time to complete, currently over 6 hours causing GitHub Actions to time out. We believe it's because internally it's using virtualization to build the arm64 version of the container.

To attempt to alleviate this, this PR uses a GitHub Actions matrix to separate the builds into runners on their own native platforms.

The hope is that the lack of needing to virtualize will speed up the overall time.

[clintjedwards]

There are two temporary changes here that I will revert once I verify that this actually builds successfully.

• I added pull requests to master as a trigger
• I explicitly set push to false

[clintjedwards]

Swapped back to the original settings! If reviewers want to review the logs for the builds they are here: https://github.com/fanout/docker-pushpin/actions/runs/16948393367

[clintjedwards]

After testing this we realized that this wouldn't build a single image with a combined manifest for the two cpu architectures, instead it would just push over whatever the first arch was. I misunderstood how Dockerhub handled this. Investigating on how to go back to a single image/manifest build without too much trouble.

[clintjedwards]

Okay I finally have what I think is a winning actions file. When a git tag is pushed it produces the following artifacts (note the version values here are an example):

• latest (multi-arch)
• 1.42.0 (multi-arch)
• latest-arm64
• 1.42.0-arm64
• latest-amd64
• 1.42.0-amd64

I've tested it here, but I'm not quite sure how to best test it for this context. I can turn off the latest flag, but if we test it in this PR it will create tags with the branch name instead of the version.

Maybe we can merge with latest turned off and then test build. Then if that works well we can update latest to on and re-run the job again?

[deg4uss3r]

What's the issue with testing and latest? Do we automatically pick up latest from somewhere else?

If so merge with CLINT or something and if that looks good, a small PR to replace to latest is a good solution.

[clintjedwards]

What's the issue with testing and latest? Do we automatically pick up latest from somewhere else?

If so merge with CLINT or something and if that looks good, a small PR to replace to latest is a good solution.

In the current incarnation of this, if we test and push a latest tag, we might have a bunch of people who are just pulling pushpin:latest that might get a version of latest that does not have one of the architectures(assuming this does not work for some reason). Which would break builds.

But yeah I think merging without latest here first and then turning it on in another small PR is the going recommendation.