build on arm runners

[niccokunzmann]

This tries out the new from @nathanlaceyraft, see #216 (comment)

This uses the arm runner for GitHub Actions.

I hope, you can see the result here: https://github.com/niccokunzmann/docker-postgis/actions

[ImreSamu]

Thanks for posting this PR !

I hope, you can see the result here: https://github.com/niccokunzmann/docker-postgis/actions

Could you please run a full test when you push the new PostGIS images to your own Docker Hub repository?

• It should run on your main branch and be modified so that the image is pushed to your own Docker Hub repository.

Previously, I found that it’s not as simple as it seems to support both architectures on Docker Hub - the last docker push tends to overwrite the previous architecture.
Because of that, I had to create a special Docker manifest.

[niccokunzmann]

the last docker push tends to overwrite the previous architecture.

Oh! That is not cool.... There should be a parameter for that but there is none....
https://stackoverflow.com/questions/66337210/is-it-possible-to-push-docker-images-for-different-architectures-separately

[niccokunzmann]

Hm.. The problem is that this is not really my use-case at the moment. I just contributed because it seemed easy for me... So, I might actually not solve this problem. I will notify the issue.

[ImreSamu]

( Regarding the Docker manifest topic )

My current test solution generates separate images:

• Internal amd64 https://hub.docker.com/r/imresamu/postgis-amd64/tags
• Internal arm64 https://hub.docker.com/r/imresamu/postgis-arm64/tags

Then, I create a manifest to merge them for end users : https://hub.docker.com/r/imresamu/postgis

The challenge is ensuring that the process works even if one of the images is not built or if the process is rerun.
I have a minimal solution for this, but I am sure it could be made even simpler.

[phillipross]

I'm still trying to catch up on all the separate efforts, but I suspect a better way to handle all of this is to use buildx caches to build platform-specific images separately, integrate that with github actions facilities for caching, then having a step which loads the caches containing the platform-specific builds from prior steps and uses buildx to build a manifest referencing the platform-specific build results and push the final manifests and referenced images to the container repository.

I'm not sure if that makes sense or if I explained it well enough, but I'm doing a form of this for other images not related to the postgis project, though I have yet to test it with GHA arm runners to see if it's workable.

Something that is necessary for this to work is to use the containerd image store which groks multi-platform images, but I haven't investigated how GHA establishes the docker environment(s) with some of these GHA actions that I'm seeing being used. I hope to get time to dig into this myself soonish, but I figured I'd drop some details here and do my best to explain 😬

As always, thanks so much for all the effort, testing, experimentation and collaboration in the attempts to come up with an acceptable solution for this!

[poush]

@ImreSamu I had the same problem, I ended up having my individual archs pushed to docker hub first and then used the outputs of those 2 jobs to start a new one to create manifest from already pushed images.

Happy to share in detail :)