Make releasing Alpha more convenient by adding gradle release plugin

[madmike200590]

Adds a basic configuration for the Gradle Release Plugin to build.gradle.kts. The release plugin

• Sets version in gradle.properties to the value passed to the plugin
• Creates a tag with the release version
• Sets version in gradle.properties of master branch to the next version passed to the plugin

Example

Running ./gradlew release -Prelease.useAutomaticVersion=true -Prelease.releaseVersion=0.7.0 -Prelease.newVersion=0.8.0-SNAPSHOT would create a tag 0.7.0 and set the version in master to 0.8.0-SNAPSHOT.

The plugin will fail if it is run on a branch other than master or if there are unversioned files present in the working directory.

Permissions

The release plugin requires permissions to directly push to the master branch. It can therefore only be run by users that are allowed to bypass the branch protection rule for master requiring approved pull requests to push. By default, these are repository admins and owners, including owners of the organization owning the repository (who are transitively repo owners).

[codecov[bot]]

Codecov Report

Patch and project coverage have no change.

Comparison is base (b16b9d6) 79.04% compared to head (af807a9) 79.04%.

:exclamation: Current head af807a9 differs from pull request most recent head 9707cdc. Consider uploading reports for the commit 9707cdc to get more accurate results

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #359 +/- ## ========================================= Coverage 79.04% 79.04% Complexity 778 778 ========================================= Files 201 201 Lines 8671 8671 Branches 1471 1471 ========================================= Hits 6854 6854 Misses 1365 1365 Partials 452 452 ``` [see 2 files with indirect coverage changes](https://codecov.io/gh/alpha-asp/Alpha/pull/359/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=alpha-asp)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[AntoniusW]

Regarding the general setup here: is it possible to not push to master but have a separate releases branch where the release bot then has write access to?

At the moment, our master is a hand-checked version of the code, hence I have great trust in it. As soon as we start to see automatic commits, this trust is gone -- obviously, we can still check all the commits done by the script after the fact, but at some point no one will do that any longer. So, I would prefer the script for releases not to commit any source to master.

[madmike200590]

Regarding the general setup here: is it possible to not push to master but have a separate releases branch where the release bot then has write access to?

That's possible, but I think it would defeat the purpose of this PR (see below).

At the moment, our master is a hand-checked version of the code, hence I have great trust in it. As soon as we start to see automatic commits, this trust is gone -- obviously, we can still check all the commits done by the script after the fact, but at some point no one will do that any longer.

I don't see the trust issue. We use a fixed version of an established plugin (gradle release plugin in version 3.0.2) that we call through a validated instance of the gradle wrapper (ensured through wrapper validation action in the workflow). All the code executed during an automated release is publicly accessible and we can go through it with a fine-toothed comb anytime if we ever feel the need to. So, in my opinion the automated release using this workflow is about the safest possible way to do it and way more reliable than a human manually executing these steps.

So, I would prefer the script for releases not to commit any source to master.

For the sake of argument, let's lay out the workflow we'd get if we release through a separate branch. I'm assuming both master and releases to be protected, i.e. both can only be pushed to using a pull request. In addition, releases can be pushed to by some bot user that's only used in the release action. 1.) Person A wants to release a new version. They create a PR from master to releases. 2.) Someone else, Person B, needs to approve the release PR. 3.) Either A or B triggers the release action, a tag from releases is created, the actual release happens. 4.) A now needs to open a new PR on master, merging back the state from releases in order to have the new SNAPSHOT version in master. All the while, no new PR must be merged into master because that would change the scope of the release (since the "release" tagged from releases does not contain what A wanted to release, but whatever was on master when B merged the PR). A possible way around that would be to have releases unprotected - but then I'd argue that just simply having the release action work in master is the safer way of going about this. And even that would not eliminate the need for the PR in step 4.

Since the idea behind this PR was to get to a less cumbersome release process that does not involve pull requests and two people, I'd very much like to do it the way I suggested.

[madmike200590]

@AntoniusW have you had a chance to think on how you'd like to move this forward

[madmike200590]

Changed the PR to only include config for gradle release plugin since I didn't find any way to have a release workflow in github actions without creating a personal access token that would be tied to my own account (or one managed by me) with way more permissions than I feel comfortable with.

[madmike200590]

@AntoniusW as discussed offline, I am merging this as-is in preparation for the next release of Alpha.