search

erlang / docker-erlang-otp

the Official Erlang OTP image on Docker Hub
https://hub.docker.com/_/erlang/
Apache License 2.0
183 stars 78 forks source link

Trigger release from OTP repo #449

Open tsloughter opened 11 months ago

tsloughter commented 11 months ago

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?

kivra-pauoli commented 11 months ago

👍 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).

epinault commented 11 months ago

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

kivra-pauoli commented 11 months ago

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).

epinault commented 11 months ago

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?

kivra-pauoli commented 11 months ago

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...