Closed intermittentnrg closed 1 year ago
Added GH actions workflow to build amd64 and arm64 images and push to github container registry for current repo
Docker images can be seen here https://github.com/intermittentnrg/grafanimate/pkgs/container/grafanimate
Build from workflow here: https://github.com/intermittentnrg/grafanimate/pull/3/checks
Hi again,
I've cherry-picked your Dockerfile into GH-24, and added our well-known recipe about OCI->GHCR publishing to it, following your intentions.
With kind regards, Andreas.
Yes I used https://github.com/docker/build-push-action instructions and examples also, but went with parallel github worker per platform per example here https://docs.docker.com/build/ci/github-actions/multi-platform/#distribute-build-across-multiple-runners. Building arm64 images with qemu can be very slow, but seems not to be an issue for grafanimate.
Also if you have any suggestions on the Dockerfile it would be great. It's a first attempt. Should maybe switch to from ubuntu to alpine for base image...
Hi again,
Also if you have any suggestions on the Dockerfile it would be great. It's a first attempt. Should maybe switch to from ubuntu to alpine for base image...
I already started to build upon your proposal on behalf of GH-24. We discourage Alpine-based images, due to subtle differences compared to glibc. Specifically when running a huge software stack including Firefox, this is even more important.
With kind regards, Andreas.
There is a alpine package for firefox available though. https://wiki.alpinelinux.org/wiki/Firefox
I try to use alpine if possible and have used it for python applications in production environment without issues.
We love the musl project, and it is becoming more mature every day. Still, we didn't regain enough trust, and don't bother too much about it. There are a few more pointers on this discussion - admitted, it's already from a few years ago ;].
Other than potential differences between musl and glibc, the package management is also different than Debian, so we would need to re-learn, or maintain a different stack. It is not worth the time for us, we are clearly on the Debian side of "maintenance convenience and peace of mind", optimizing for re-using well-established recipes across all the projects we maintain.
It's basically just apk add firefox-esr
instead of apt install firefox-esr`. But yeah we can discuss this later. Might add a Dockerfile.alpine later tho and see how it goes...
It's basically just
apk add firefox-esr
instead ofapt install firefox-esr
.
It is not about this specific recipe. It is about that we want to use the same kinds of recipes across many projects, and need to keep a reasonably universal setup to keep our sanity. Thanks for your understanding ;].
GH-24 has been merged, therefore I am closing this. Thanks for all the fish.
A work in progress submitted for any feedback.
Since some animations take some time to render, especially with --exposure-time, and before I added #19, I thought I will run it as container from pipeline.
You may notice I don't usually write python. Submitted for early feedback.
Also it should build container from github actions and push image to github container registry.