ci: add & configure release-please

[thor]

Adds release-please by configuring the release-please GitHub Action.

The action provides a continually up-to-date PR that can be merged when the main branch is ready to be released as a new version. Through conventional commit messages it'll determine what the next version number is.
The release-please explains what this does and how it is intended to be used.

[thor]

@blt950 note that the errors are expected as I'm configuring the action and the manifest in one PR. I could split them out into separate ones though, if you'd like 🟢 first, but I've tested it locally and will fix-forward in the event of anything... strange.

[blt950]

@thor I've taken a brief look. I've never used this before, so bear with me. I understand that this CI will make all commits into a main into a pull request. This pull request will collect all commits to create a changelog and suggest(?) a version number bump that is commited when PR is merged. We'll still need to manually click "release" by merging the PR.

Changes we need to do in our pipeline and habits:

• Commits need to be written in a very specific way
• We don't need to write changelog manually anymore (though we still will do it for the #status-update channel in VATSCA, because it usually is simplified into a non-techy wording and explanations).

Some control questions:

• What is the advantage of doing it this way?
• What are the disadvantages of using this?
• Are we overcompliacting something that is not a challenge today?
• What do we do with commits that are not well written? E.g. merged from a external PR, a hasty push, just forgetting the new formating etc.
• Is this in line with our "there might be a another web team in future that is not as techy as we are and will be able to cope"-mantra?

[thor]

@thor I've taken a brief look. I've never used this before, so bear with me. I understand that this CI will make all commits into a main into a pull request. This pull request will collect all commits to create a changelog and suggest(?) a version number bump that is commited when PR is merged. We'll still need to manually click "release" by merging the PR.

@blt950 Yup, that's right. Committed and released.

Commits need to be written in a very specific way

I'd challenge "very specific" and say a "specific" way, and even that is still optional as you can override previous commits.

We don't need to write changelog manually anymore (though we still will do it for the #status-update channel in VATSCA, because it usually is simplified into a non-techy wording and explanations).

You'd still need some human changelog, at least if you want to target users or humans.

What is the advantage of doing it this way?

Less administrative and duplicate work when releasing new versions, as you don't need to create releases manually. You get both GitHub Releases and tags. It works well whether you release often or if you want to bundle up multiple changes before releasing. It allows you to think of the changes in each of the changes and leave the versioning to something non-human. Less likely to give users update fatigue (if one believes in such a thing 😉).

You get a gate for releases where you get to evaluate the changes ahead of releasing them. You can edit the changes after having made them. You get to see all changes queued for a release in an overview.

You get a prettily formatted set of release notes.

What are the disadvantages of using this?

You're likely to release less frequently than if you automated the release mechanism entirely. You have to approve the release manually. There's always a pull request open. You have to know what the difference between fix: and feat:, as well as fix!: or feat!: is, if you want the changelog to make sense.

Are we overcomplicating something that is not a challenge today?

Like with most things, it's opt-in. Nothing breaks if you do it manually instead, should it fail or be unusual, or if you're feeling like it's Monday.

• What do we do with commits that are not well written? E.g. merged from a external PR, a hasty push, just forgetting the new formating etc.

You use the override functionality described in its documentation.

Or, you can ignore it and just add it to the release after the fact if you're releasing it with other things. 🤷

Is this in line with our "there might be a another web team in future that is not as techy as we are and will be able to cope"-mantra?

It's far easier to opt out of than most of our things, as you can ignore the PRs or remove the workflow. If you don't understand it, it won't do anything. It won't prevent you from doing anything if you don't know it's not there.

However, if you do use it, you're making a release process arguably easier rather than harder. I'd at least argue that the amount of knowledge and style you know about and utilize when you release a new version should be codified rather than a bus factor of 1.

I'd guess, at some point, it'll be removed because something else is more enticing or because it's not needed. Hard to say what the future will bring.

Nothing depends on it, unlike controlcenter itself.

[blt950]

Thanks for the info, let me think about this next time I do some fixes in CC so I've the right mindset. I'll follow up with a decision.

[thor]

Thanks for the info, let me think about this next time I do some fixes in CC so I've the right mindset. I'll follow up with a decision.

Bump. We can always close this for the time being and leave the branch present. FWIW, besides the initial noise in the pull requests, it's possible to test and revert this if you'd like, or test it in a fork.

[blt950]

Keep it open. I'm slowly trying to work on my habits to write "correct" commits for this, once I'm confident we can merge this in :)

[blt950]

@thor Just follow up question:

• As I understand it'll create a PR based on the commits in main, but where does it pull into? A new version like branch?
• Since it creates an PR, it'll be possible to use this without command line, correct?
  • If for some reason we disagree that next update is a major instead of a minor. Can this be solved without command line?

[thor]

@thor Just follow up question:

@blt950 No worries.

As I understand it'll create a PR based on the commits in main, but where does it pull into? A new version like branch?

That's right. It pulls it into its own "release-please--" branch, from which it creates the pull request.
In other words, you can try it out and all that it'll do is create (and update) the pull request.

Since it creates an PR, it'll be possible to use this without command line, correct?

Affirmative.

If for some reason we disagree that next update is a major instead of a minor. Can this be solved without command line?

Affirmative. You can alter already-merged changes, or you can override the version manually.

[blt950]

Behind the #643 and #638 have merged, cleared line up and merge this as well, behind.