Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trigger release from OTP repo #449

Open
tsloughter opened this issue Sep 24, 2023 · 5 comments
Open

Trigger release from OTP repo #449

tsloughter opened this issue Sep 24, 2023 · 5 comments

Comments

@tsloughter
Copy link
Contributor

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
Copy link

👍 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
Copy link

epinault commented Oct 4, 2023

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
Copy link

kivra-pauoli commented Oct 6, 2023

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
Copy link

epinault commented Oct 6, 2023

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants