Release Operator to support changelog extraction

[hendrikmaus]

With #391, we put the new release-operator in place. the workflow will also create the respective GitHub Release resource with all binaries and their checksums attached. However, the body of the release resource won't contain any changelog. In fact, it will default to the last commit message as of now.

Hence I would propose to extend the release-operator to extract the relevant part of the changelog file. It can then be put into the Release resource upon its creation.

Since the headlines in the changelog always start with the SemVer identifier, it should be enough to parse the document with three values given: path to the changelog, previous tag, current tag:

• Read the file into memory
• Look for the headline that begins with the current tag
• Consume until the headline with the previous tag is found
• Write the consumed portion to a temporary file
• Use the temporary file's contents as body when creating the release

[hannobraun]

Honestly, I don't think that's worth the effort. Since releases are pretty prominent in the GitHub UI and shown to my followers in their timeline, I view releases rather as a user-facing announcement, and less of a "technical details for nerds" thing, which is what the changelog is. Therefore, I want the release to show the full release announcement, with high-level description, screenshots, etc.

While the changelog would certainly be a better placeholder than the last commit message, I don't think it's worth to write code to extract it, if I'm going to replace the contents anyway.

I have two alternative suggestions:

1. The low-effort one would be a simple placeholder message, stating that the release has been create automatically, and that a release announcement will be added momentarily.
2. Extract the release announcement from the website.

I think I'm doing a decent job with the HTML I generate on the website, so the second point should be relatively straight-forward, actually. The procedure would probably be something like this:

1. Take main > article.
2. Filter out header, aside, footer.
3. Add new title based on version, or extract title from header.

The only question is, how well will that HTML play with the Markdown input that GitHub accepts. In principle, it should be valid Markdown, but I don't know if GitHub is filtering any tags.

[hendrikmaus]

According to the GitHub Markdown spec, that could work out just fine:

Text between < and > that looks like an HTML tag is parsed as a raw HTML tag and will be rendered in HTML without escaping. Tag and attribute names are not limited to current HTML tags, so custom tags (and even, say, DocBook tags) may be used.

Source: https://github.github.com/gfm/#raw-html

Let's go with the release announcement from the website then.

[hannobraun]

In an effort to keep the number of open issues down to a reasonable number, I'm folding this issue into #104. I'll close this one and add a reference to it over there.