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 :)

[murbanowicz]

@phillipross do you need any hand on this?

[phillipross]

@phillipross do you need any hand on this?

Thanks @murbanowicz ! I personally simply need time to dedicate to wrapping my head around the various challenges and issues and taking the time to test my ideas, but @ImreSamu is closer to all of it at the moment than I am. Currently I'm at a point where I have some biases and complaints about docker and github actions in general that I need to overcome, and that requires me to test some of the ideas that I tried to convey earlier in this PR.

I'd like to re-state that I think the key to getting a solid workflow requires utilization of docker caches that cache platform-specific builds, persist them to GHA caches which can be used by subsequent GHA build steps, and then a downstream GHA process restore those caches and compile the final multiplatform image (platform-specific images and image manifest) and push them to the final container registries. Anybody who'd like to try to prototype something like that is welcome to try, and maybe we could turn this into a somewhat async collaborative approach 😁