Migrate mandrel-release.java to JReleaser

[zakkak]

Back in March 2022 @aalmiray rightly pointed out that most of the things we do in our custom release script can be performed by JReleaser.

I took the chance today morning at JCrete's hack session to "play" with it and create a partial configuration for mandrel. We also had an informative discussion with @aalmiray afterwards that helped me answer any questions I had.

Overall, it looks like JReleaser could replace our mandrel-release script and among others add support for:

1. automated gpg signing before uploading assets
2. automated announcements to various channels

I will keep experimenting with it the following days till I can hopefully replicate our current process on it. If there are any objections, let me know. cc @Karm @jerboaa

[Karm]

"+0: 'I don't feel strongly about it, but I'm okay with this.' "

[galderz]

+1 I'm all for it assuming it reduces what we need to maintain on our side.

[zakkak]

Switching to jreleaser would change our changelogs to look like:

## What's Changed
* Sync 23.0 upstream branch with mandrel/23.0 by @zakkak in https://github.com/graalvm/mandrel/pull/528
* Make graal-sdk artefact JDK 11+ compatible by @jerboaa in https://github.com/graalvm/mandrel/pull/533
* Bump version to 23.0.1.0 and mark as non-release [skip CI] by @zakkak in https://github.com/graalvm/mandrel/pull/534
* [23.0] Restore ability to disable debuginfo stripping by @zakkak in https://github.com/graalvm/mandrel/pull/536
* Mark suites for 23.0.1.0-Final release by @zakkak in https://github.com/graalvm/mandrel/pull/535

**Full Changelog**: https://github.com/graalvm/mandrel/compare/mandrel-23.0.0.0-Final...mandrel-23.0.1.0-Final

Instead of the more informative version we use now: https://github.com/graalvm/mandrel/releases/tag/mandrel-23.0.0.0-Final

This is because although JReleaser supports arbitrary changelog templates, at its current state it only supports changelogs listing commits and not pull requests. If one wants to list pull requests as the changelogs they have to use github's automated release notes which results in something like the above (we can still filter PRs and categorize them as backports or notworthy, but we can't add arbitrary prologues and epilogues).

To me this is not a huge deal TBH. Most of the parts listed in our current release notes actually belong in the README file

If this seems like a major drawback it might be worth exploring the possibility of extending JReleaser to support PRs as well.

[aalmiray]

FWIW templates may be applied to add content around the commit msg generated changelog. JReleaser itself does this. You may also edit the generated changelog once published. Of course, if the changelog is published by JReleaser to other channels at the same time you may loose the ability to make adjustments after the fact.

Natively generating the changelog with just (or additionally to) PRs is a feature found in our roadmap but we have yet to schedule it for impl.

Moreover, in the future it will be possible to reformat the whole changelog, group commit msgs into single paragrapahs, link to external sources, inject snippets, or whatever makes sense ro make the changelog more palatable to readers.

[zakkak]

Natively generating the changelog with just (or additionally to) PRs is a feature found in our roadmap but we have yet to schedule it for impl.

@aalmiray would you be willing to accept a github specific implementation in the meantime? And if so, can you make an estimate of how hard it would be to implement? I.e. is it mostly a matter of adjusting the changelog generator based on the commits or do we need a completely new implementation? I am asking because if you think it wont' be too hard (for someone not familiar with the codebase) I could give it a try.

[aalmiray]

Sure, we can start with just GitHub. REST APIS for other git services are not that different, thus the additions would not be that difficult to adapt at a later stage.

In particular, implementing a new feature that touches the DSL (such as this one as users would have to configure at least 1 property to opt-in) requires updating 3 model classes (read only, mutable, gradle) plus changes to the GitHub SDK itself. I can guide you through 😅

[zakkak]

OK, let's take the discussion to https://github.com/jreleaser/jreleaser/issues/816 :)

[github-actions[bot]]

This issue appears to be stale because it has been open 30 days with no activity. This issue will be closed in 7 days unless Stale label is removed or a new comment is made.

[aalmiray]

ping