Add a GHA to create Github releases

[gforcada]

GitHub has this concepet of creating releases out of tags, where one can also add a nice description with markdown etc.

It also serves as a marketing tool, as a mildly involved user can subscribe to a package to only to get notifications of new releases.

[gforcada]

We can re-use some code from scriv maybe: https://github.com/nedbat/scriv/blob/main/src/scriv/github.py 🎉

[gforcada]

Actually, creating a release is mostly a matter of doing a GitHub API call, and within a GHA one can use the GITHUB_TOKEN to do so: https://docs.github.com/en/actions/security-guides/automatic-token-authentication

So, we need a way to gather the information for the release and push the data, basically what scriv does 😅

[gforcada]

Actually, creating a release is mostly a matter of doing a GitHub API call

Famous last words 🤦🏾

BUT, after a day long of banging my head against the world, behold the Frankenstein 👹

A GitHub Action that massages CHANGES.rst (so far only .rst) to get the last changelog entries, manually creates a JSON payload and finally, via the GitHub REST API, creates a release 🎉

I spent an absurd amount of time trying:

• fighting to pass data between two steps (one two extract the changes, the other for the REST API call): multiline data is far from optimal
• fighting to get the quoting/escaping combination to work: fortunately curl is great in that you can write the JSON data in a file and get it read by curl ✨

One last caveat: if you are using zest.releaser and/or manually adding [ci skip] to the tag commits, then the GitHub pipeline does not run either 😮‍💨

Oh boy! what a ride 🎢

@ericof @mauritsvanrees how does that look like? 😅 it is worth pushing it here to plone/meta and start testing it?

The release workflow does not change at all: one still needs to create the release (with zest.releaser or such) and the GHA will create the GitHub release (if no [ci skip] is on the commit).

[mauritsvanrees]

@gforcada Thanks for working on this!

I tried the script locally. On my Mac sed -z says "illegal option". I suppose that works fine on Linux. Other than that, it seems to work.
It would be good to also work on CHANGES.md, or at least not fail with an error when CHANGES.rst is not there. But can be handled later.

But the [ci skip] is a problem. :-/ I don't think we want to remove [ci skip] from the recommended zest.releaser config. And I did not yet find a way around this limitation in GitHub Actions.

[gforcada]

Yes to all :)

• as I was testing it with a package that had a .rst file I used that, but indeed, we have to make the monster even bigger to also handle .md
• the -z is indeed a Linux thing, to remove spaces, I actually had a python script to do mostly the same, but I did not want to have external files 😕 and creating a GitHub Action only to extract a bit of text seems overkill to me... but on a second thought, it might be a good idea at the end, so we can more easily handle not only .rst/.md but also pre-releases, and all the things that a GitHub release brings
• and finally, yes, the [ci skip] is indeed problematic... changing all our workflows (jenkins, GitHub Actions from plone/meta, etc...) only to please this minor part feels overkill and a lot of work...

💡 but can we actually tell zest.releaser to add the [ci-skip] only on the Back to development... commit? I see potentially other automations that we could do with a pipeline running on a tag commit, i.e. automatically update buildout.coredev version pins, so if someone does not make the release with plone.releaser but plain zest.releaser, or even simple python -m build && twine upload dist/* we would still be able to get the releases updated in buildout.coredev... And with mr.roboto monitoring for releases we could know to which buildout.coredev branch a new release should go...