Hi,
I was wondering if it could make sense to automatically start building and releasing the Erlang docker images upon each release by making use of Github Actions? Is this something that the OTP team would be interested in?
This also could be an opportunity to improve the Erlang docker image tagging scheme to include the base distro (bookworm vs bullseye) as discussed here: update 26 branch debian base image by pilou- · Pull Request #447 · erlang/docker-erlang-otp · GitHub
Could we do the same for the official erlang docker images?
While the repo for the Erlang images resides in our organization, we do not maintain them (just as we do not maintain rebar3). So you will have to talk to the people maintaining those images.
But the otp repo is where release actions can be triggered. It wouldn’t need to actually build the docker image in the otp repo but it could send a webhook to the erlang/docker-erlang-otp github actions workflow could trigger and do the building.
Assuming maintainers of erlang/docker-erlang-otp are open to that do you think a PR to call the webhook may be accepted into erlang/otp repo?
Yes, we have no problem with adding such a trigger.
This would be nice for the otp-macos repo that @paulo-f-oliveira and I are starting, though it doesn’t live under erlang org, so that might not be great security wise.
I’m sure we can figure something out that would work and be secure for repos in other organizations as well.
Considering that the “official” images are maintained by neither the erlang/elixir core teams, nor Docker, I think the name is quite a misnomer and a large source of confusion.
Over a year ago I attempted to add a note to the readme for the elixir image, highlighting some of the issues with these images and pointing people to the hexpm version, but it’s so far only helping the local dust population. Update elixir to link to alternative and similarly official images by adamu · Pull Request #2206 · docker-library/docs · GitHub
I wonder if it would be worth trying to consolidate the “official” and hexpm images?
They behave quite differently, with the “official” ones retroactively upgrading the same tag with newer underlying underlying OS (and in Elixir’s case, OTP) layers. This can be useful because you don’t need to opt in to every minor update. However, I think that most people would actually prefer the default behaviour of the hexpm images - where a tag contains the relevant version numbers and is never updated - if you want a new version, you use a new tag.
They can’t be fully consolidated because Docker requires images to be tagged the way the official Erlang and Elixir images are if they are to be official.