Improve release automation

[lkubb]

This commit introduces several helpers:

• A script that reads the most recent released version from CHANGELOG.md and can be instructed to guess the next version based on news fragments.
• A new workflow that renders the changelog and submits a PR with this changelog.
• A new trigger for the release workflow that runs when pull requests are closed and checks if it was a release PR as created by the workflow described above.

In conclusion, this patch allows to quickly release new versions instead of having to perform the above steps manually on the CLI.

Fixes: https://github.com/salt-extensions/salt-extension-copier/issues/18

[lkubb]

@max-arnold Could you review this please? I like the simplicity of the new release process for maintainers, but could use another pair of eyes since the implementation is a bit tricky.

This optimizes for the usual case where releases are cut in a linear process from the default branch, brushing over many corner cases probably. I'm fine with this since extension projects should be kept simple. The manual release by tagging still works to account for more custom processes.

[max-arnold]

Sorry for the delay. Will take a look early next week.

[lkubb]

The resulting GH workflows are quite complex for me to review in a meaningful way

No worries, I was primarily hoping for general comments/suggestions. :) Wasn't sure if there were obvious gotchas with this approach/workflow that I was missing.

1. Am I correct that it will generate a release PR even if I just push my changes directly without making a feature PR?

Yes, but only if there is at least one news fragment to render.

2. What will happen if I push two changes that contain changelog items? Will it result in two release PRs?

No, there will always be at most one open release PR (which is updated when new changes are pushed).

3. Will the docs get rebuilt properly (i.e. contain the updated changelog) after I merge an automated release PR?

The automated release PR only builds the changelog (which would have needed to be done manually before). Merging it triggers the same workflows as when pushing a new tag, i.e. the docs are regenerated and published as always. The only issue is the release date - if the automated PR was generated day(s) before merging it, the release date is off.

4. For automated tagging, are there any benefits in using annotated tags?

I don't see any, do you have suggestions?

[max-arnold]

I don't see any, do you have suggestions?

Annotated tags have explicit attributes that might be useful to tell who and when made them:

• Tag author
• Date
• Message

Also they are (kind of) immutable.

But it is just a suggestion to consider.

[lkubb]

@max-arnold Thanks a lot for the suggestion, TIL. I assumed all tags were treated as git objects and were thus "immutable".

I'll set create_annotated_tag: true in the tag action to make it work as intended.