Docker image workflow (publish on ghcr.io)

[AFCMS]

Should fix #14164

Follows the official Docker documentation to build image using GitHub Actions workflows.

Official Actions by Docker are used.

Links:

• https://docs.github.com/en/actions/publishing-packages/publishing-docker-images
• https://docs.docker.com/build/ci/github-actions/multi-platform
• https://github.com/opencontainers/image-spec/blob/main/annotations.md

Tags are automatically determined by the Docker metadata Action.
You can find how its done here

Please note that the build of the arm64 image takes a much longer time than the amd64 one. This is due to the use of QEMU for the build process, following the Docker documentation. It may be possible to not require the use of QEMU by modifying the Dockerfile but I don't have the knowledge to do so.

To do

This PR is a Work in Progress.

• Basic stuff
• Test if build works (on fork)
• Is opencontainers metadata correct for the images?
• Should the workflow use a matrix strategy for the architectures? No more arm64
• Remove old image building workflow?
• Test running --version in CI
• More architectures? (alpine supported architectures) Or remove arm64? Require cross-compilation support in Dockerfile.

How to test

Merge the branch into one of your forks of Minetest, see the workflow run, see the container in the package section of the repository. See the two architectures. Pull the image and see if it runs.

In my case:

• https://github.com/AFCMS/minetest/actions/runs/7448427624/job/20262783153
• https://github.com/AFCMS/minetest/pkgs/container/minetest
• docker run ghcr.io/afcms/minetest:master /usr/local/bin/minetestserver --version works

[sfan5]

Please note that the build of the arm64 image takes a much longer time than the amd64 one. This is due to the use of QEMU for the build process, following the Docker documentation. It may be possible to not require the use of QEMU by modifying the Dockerfile but I don't have the knowledge to do so.

The use of qemu cannot be avoided since Github does not provide any ARM runners. I'd simply drop it.

[AFCMS]

The use of qemu cannot be avoided since Github does not provide any ARM runners. I'd simply drop it.

Isn't arm support interesting enough for raspberry pi users? The CI is basically free so my biggest concern was the longer time for the CI to finish in stuff like PRs. That could perhaps be improved by using a matrix strategy so the two builds are visually separated.

[AFCMS]

Docker support cross compilation in the image build process, but it requires modifications of the Dockerfile.

https://docs.docker.com/build/guide/multi-platform/#build-using-cross-compilation

GCC is also not straightforward to setup for cross-compilation, so I think its better to just drop the QEMU based arm build and later think about allowing cross-compilation in the the Dockerfile.

[AFCMS]

I dropped the arm64 support. IMO it would be a good thing to support it, but it should be done with cross-compilation support in the Dockerfile.

[AFCMS]

On the topic of cross compilation, this seems to be a pretty useful tool:

https://github.com/tonistiigi/xx

[sfan5]

Hmm, now it doesn't run for the PR anymore?
or is that because we just added it?

[AFCMS]

Failed to start: https://github.com/minetest/minetest/actions/runs/8254040414

[AFCMS]

I have tried adding back the kubernetes.yml file, but my IDE shows some errors

I never used Kubernetes and don't have the knowledge to fix those. I think I will just drop it (could be added back later if needed).

[AFCMS]

I still need to fix the image metadata

[AFCMS]

I have put LGPL-2.1-only as SPDX license identifier for the Docker image metadata.

Is it fine or should I go with the LGPL-2.1-or-later ?

For reference: https://spdx.org/licenses

[rubenwardy]

Looks good apart from that

[rubenwardy]

Looks good

[AFCMS]

On a side note after merge the package should be set as public in it's settings. At least on my account it's private by default and only visible to the repository maintainers (it's confusing IMO, there is no clear indication that it's private in the maintainers view).