Improved Docker image + publish on ghcr.io

[AFCMS]

Fix #610

• Native cross-compilation support in Dockerfile. Only linux/amd64 and linux/arm64 supported and tested (Tier 1 platform support from Rust)
• Cache support for cargo downloads and compilation results in Dockerfile
• Open Container's annotations in Dockerfile
• GitHub Actions workflow to build the image for both platforms, publishing to ghcr.io on tags and master branch pushes.
• Disable use of GitHub Actions cache for tags build, allow manually triggering the workflow with or without cache.
• Attestation artifacts for builds
• Add basic informations about the use of the Docker image in README

I also changed the WORKDIR from /src to /work, because if got me confused with the use of the src folder for the project source in the first stage of the Dockerfile. It doesn't impact anything anyways since you can mount the file where you want and have the program options point to it.

How to test?
After checking out the branch and making sure you have QEMU installed to build/test

# Docker sadly doesn't have yet the way to have locally a tag with multiple platforms
# despite being able to pass multiple platforms to the build command, so we have to use two distinct tags.
docker build --platform=linux/amd64 --tag test-oxipng-amd:latest --load .
docker build --platform=linux/arm64 --tag test-oxipng-arm:latest --load .

docker run --rm test-oxipng-amd:latest --version
docker run --rm test-oxipng-arm:latest --version

# Run on some files
docker run --rm -it -v $(pwd):/work test-oxipng-amd:latest -a /work/tests/files/apng_file.png
docker run --rm -it -v $(pwd):/work test-oxipng-arm:latest -a /work/tests/files/apng_file.png

# Remove the images
docker image rm test-oxipng-amd:latest
docker image rm test-oxipng-arm:latest

For the workflow, see the GitHub Actions logs. If you want to test the ghcr.io publishing you can merge the branch into a fork and see the result.

[AlexTMjugador]

Looks good to me! I'd merge this after hearing @shssoichiro's thoughts about setting up the GitHub container registry for this repository. Great work on the documentation, Dockerfile and workflow. Thank you.

That said, as I mentioned in #610, I'm curious about what value these Docker images provide over the portable musl binaries. I understand that Docker images are often requested for CLI tools, and that’s fine, but why exactly in this case? What specific problem does this solve for you?

Edit: I've just rebased your PR on top of the latest mainline commits to fix unrelated Clippy lint issues, please don't mind it 👍

[AFCMS]

I don't have a really specific usecase, I did this PR mostly as a training for both Docker and Rust 😅 (I use the tool with cargo install usually)

Anyways, I think the benefit of a Docker container over the portable binary is that you don't need to go to the download page, extract the binary and then go back regularly to check if there is any new version.
With Docker you can just run the command in documentation with the latest image and the --pull=always flag, so it will download or update if needed and run the program automatically.

[AlexTMjugador]

Thanks for the comment @AFCMS, I do indeed realize now that the convenience of unifying software distribution through Docker containers can be valuable. Let's wait a bit for Josh's view on using GitHub Packages before merging 🚀

[andrews05]

I wonder if it would be better for someone to maintain this externally from the main repo...

[AlexTMjugador]

I wonder if it would be better for someone to maintain this externally from the main repo...

I think it's more discoverable and official-looking to use the same repository both for Docker images and development, but anyone is free to create a repository for hosting their own OxiPNG Docker images of course.