docker-erlang-otp
docker-erlang-otp copied to clipboard
erlang
Trigger release from OTP repo
OTP team would have no problem including a trigger on the otp repo's github actions on release to update this repo https://erlangforums.com/t/automatically-building-and-releasing-erlang-docker-images/2889/6. I will look into a PR for them and here that sends the hook from the otp repo to this repo.
Big question is how automated should it be. I take it that at first people would be most comfortable with it just opening a PR to update version?
👍 good stuff, @tsloughter. My experience tells me a pull request would be best, to start. If e.g. the main branch is protected there's no easy way (that I know) to do the auto-merge (because you need push rights). And it's usually protected for security reasons (as I'd imagine the actions' SHA are and so on).
can we automate the pull request ? cause I saw the exact same thing with elixir and had to push an MR to get the new version but I would think that we can fully automate the flow when a release is out?
I see that both
26.1 26.1.1
are released in asdf
That's because asdf uses kerl behind the scenes, and kerl goes to GitHub directly, so it's basically as-updated as the tags that come out... 😄 (but if kerl gets updated asdf doesn't - at least for the base functions, because it's relying on a hard-coded default release version, bumped by hand)
On the other hand, for the automation bit, it should be possible, as long as there's enough checks to make sure you don't publish an image that is not usable (I don't know what kind of checks the maintainers do to guarantee that, but those should potentially be replicated in CI).
I mean : Github API + workflow can be done right? run as daily or weekly job, check new version, generate new file , get and. MR that may need adjustment but at least the MR exists and helps providing visibility for approval. Then normal process for the rest (and even upstream MR auto created too on merge?) . I don t know the full process for those repo so just an idea?
If it's creating a pull request, yes, it should be possible to automate. What I was advising against, at least initially, is fully automating "pull request + approval + merge" which is possible too, but maybe should be done later...