Add initial release-drafter workflow

[martinhoyer]

To further automate the release process, I've been looking into github releases. After evaluating various options, like .github/release.yml, I'm proposing release-drafter , which seems to be the most popular tool specifically for this.

The initial template aims to keep everything as is, but could be a base to further improve the release notes (see available configuration options)

Note I've added:

exclude-labels:
  - 'ignore-for-release'

this, or some similarly named label could be used for merges that should be omitted from release notes, e.g. single-line typo fix that blocks release :)

TODO:

• use replacers for tmt rtd link

[martinhoyer]

This would require consistent versioning in tmt.readthedocs going forward. For example: 1.35.0 as opposed to 1.35.
Historically, it has not been the case: e.g. tmt-1.32, tmt-1.32.2.

[LecrisUT]

There is a similar action changesets/action (example) which instead of creating draft releases, it creates an "immortal" PR. Wdyt about that workflow?

[martinhoyer]

There is a similar action changesets/action (example) which instead of creating draft releases, it creates an "immortal" PR. Wdyt about that workflow?

Not sure about this tbh.
I think in tmt we only need to automate the gh release notes, and quite possibly the check for new contributors, at least with the current workflow, i.e. keeping github release notes short-ish and documenting the more interesting changes in rtd in more detail.

[LecrisUT]

The main difference is that with the draft releases is that it is only visible to GH contributors, while the PR is more interactive. changesets/action itself, I don't think it's a good action here (because it is focused on npm projects), but the workflow it implements is the main thing to consider here.

[martinhoyer]

The main difference is that with the draft releases is that it is only visible to GH contributors, while the PR is more interactive. changesets/action itself, I don't think it's a good action here (because it is focused on npm projects), but the workflow it implements is the main thing to consider here.

Well, there is docs/releases.rst for that.

[psss]

I think for now the main use case is covered quite well by #4319.