[Feature] Improve release tooling

[lkubb]

Cutting a new release is currently more involved than I would like (https://salt-extensions.github.io/salt-extension-copier/topics/publishing.html). This is caused by the towncrier design.

Imo, this process should be cut down to a single step. The issue is that the changelog needs to be built somehow and be included in the tag. Solutions I came up with so far:

Retag

• The maintainer pushes a new tag.
• Usual CI runs.
• Before running the release workflows, a separate workflow does the following:

1. run towncrier build
2. commit & push
3. remove tag + github release, tag the new commit with the previous version

• then the release workflows run (this needs to happen in the same event, it does not trigger a new one)

Benefits:

• intuitive

Drawbacks:

• still requires CLI

Issues with this approach:

• the tag must happen on a branch tip
• If towncrier renders invalid Markdown, the docs build job does not catch it
• Doesn't play well with legacy branch protection, might need repository rules (https://github.blog/changelog/2023-04-17-introducing-repository-rules-public-beta/)
• The local tag is out of sync
• Seems brittle

Automated PR

Basic idea from here: twisted/towncrier#585 (comment)

The idea is that any pushes to the default branch trigger a workflow that builds the updated changelog and submits a PR from a release/x.y.z branch with the changes. It automatically determines the semantic version by defaulting to a patch bump, unless it finds

• .added.md (minor bump)
• .removed.md / BREAKING in a description (major bump)

Merging this PR then triggers a tag + release workflow.

Benefits:

• simple since it automates the towncrier design, does not work around it
• can be accomplished only from the browser
• still allows manual intervention

Drawbacks:

• designing the second workflow might be tricky

Issues with this approach:

• maintainers should take care to ensure the rendered release date is correct