Add releases for main & maintenance branches #13829
Conversation
Before this patch, release.yml workflow was only compiling and publishing builds on tag pushes. This patch additionally handles branch pushes (main, v1.17, etc) and publishes them to corresponding releases (main-latest, v1.17-latest, etc). When we first looked at using GitHub releases for main builds, we discarded the idea because we didn't want to keep re-creating (and thus sending out notifications) releases. There was no API to update the SHA the release was pointing too either. It's obvious in hindsight but all we need to do is to update the _tag_ with the latest SHA and force-push the tag that the release is pointing to. We now have two places where we build main and maintenance branches, release.yml and builds.hex.pm.yml, so in future commits we should look into unifying the two.
|
@wingyplus any feedback on this would be very appreciated. If this lands, perhaps you'd be interested in helping out with unifying release.yml and builds.hex.pm.yml? I think we can have a single workflow where we precompile per OTP once and publish the exact same artifacts to GitHub releases and builds.hex.pm. |
|
One more demo, from my fork: https://github.com/wojtekmach/elixir/releases |
|
cc @tsloughter |
|
Are you able to tell it to not add the |
|
Ah yup. Can you add |
|
Side question: Does Elixir do any backporting of fixes? Like are releases of older versions still being done? Like Erlang does but you can see that the latest 26 release is not |
|
I added —-latest=false, thanks! yes, Elixir is backporting some fixes on eg v1.17 and similar branches and cuts eg v1.17.(n+1) off of it. |
|
We now publish releases off git tags on CI so maintenance releases would by default be marked as latest which is not what we want. I can look into conditionally doing that when they are in fact latest. |
| —-latest=false \ | ||
| --title $ref_name \ | ||
| --notes "Automated release for latest ${{ github.ref_name }}." \ | ||
| || true |
There was a problem hiding this comment.
We can't ignore this step, right? The prebuilt step requires the release to be presented.
There was a problem hiding this comment.
this particular gh release create will succeed only ever once per branch so I thought it's OK to ignore errors. I could make it more explicit or at least add a comment though.
|
💚 💙 💜 💛 ❤️ |
@wojtekmach will help looking into this. 🫡 |
Before this patch, release.yml workflow was only compiling and publishing builds on tag pushes.
This patch additionally handles branch pushes (main, v1.17, etc) and publishes them to corresponding releases (main-latest, v1.17-latest, etc).
When we first looked at using GitHub releases for main builds, we discarded the idea because we didn't want to keep re-creating (and thus sending out notifications) releases. There was no API to update the SHA the release was pointing to either. It's obvious in hindsight but all we need to do is to update the tag with the latest SHA and force-push the tag that the release is pointing to. So it is logically the same release but we update the SHA (through tag) and upload updated release assets.
Demo:
We now have two places where we build main and maintenance branches, release.yml and builds.hex.pm.yml, so in future commits we should look into unifying the two.