Create a release

[CSchoel]

Since we can now generate executable JAR files from the project, a release should be added on GitHub for each new project version including the JAR files as downloadable abstracts.
Ideally, a release workflow can be added through GitHub actions.

Note: This issue is still work in progress, as it is not designated for the current sprint.

[manuEbg]

I created a separate branch to play around with our github action.
I turned of testing in the action to speed it up
and managed to take the version specified in build.gradle and tag the latest commit with it.
As intended the job fails if there is already a commit tagged with that version.

[manuEbg]

I noticed that tagging the commits via the action already created a release for each new tag. The releases only contain our source code packed in archives, but hey that's more than I thought ☺️😎😵

[manuEbg]

OK my latest commit created this release.
After a bit of configuration hustle i successfully tested the Jars included in this release. (and think #35 requires a view improvements...).
So the next step to complete this issue would include:

• reactivating tests
• separating CI from CD
• Creating a changelog and use it as release body (probably related to Keep a changelog #105)
• trigger release action only from main branch
• maybe find a smother and more flexible way to get the path of the jars
• find out why the release is connected to the latest commit on main?? (probably because i didn't use

target_commitish:
    description: "Commitish value that determines where the Git tag is created from. Can be any branch or commit SHA."
    required: false

Note: please feel free to add steps i haven't thought about

[manuEbg]

adding target_commitish fixed the issue regarding tagging the wrong commit...
see softprops/action-gh-release#76

[CSchoel]

A few tips from my own experience:

I moved from actions/create-release (which is now discontinued) to softprops/action-gh-release (which I found a little finicky/buggy) to just using the GitHub command line interface that is installed per default on all GH Actions runners. You can find an example of how to use the GH CLI tool to create a release in my SHM project.

Also, If you want to, you can use my own GitHub action for creating release notes from a changelog. It also creates an environment variable named $RELEASE_VERSION for you, which contains just the version string from the environment variable $GITHUB_REF. This can be useful for naming artifacts like JARs.

Also note that while GitHub displays tags as releases, a full release is still something different that is also handled a little different in the GitHub interface. However, releases are usually tied to tags, so the distinction is not that clear cut.

Something I found I had to do quite often when testing my releases was deleting and re-creating a tag name after I fixed a small bug in the script. To do this, you can use the following commands:

# delete local tag
git tag -d myTagName
# delete tag on server
git push --delete origin myTagName
# re-create local tag
git tag myTagName
# push tag to server
git push --tags

[manuEbg]

I also noticed that actions/create-release is discontinued and switched to softprops/action-gh-release, which i quite liked:)
I am wondering if I understood your GitHub action for creating release notes from a changelog correct.
If i want to create Release v1.0.0 your action searches for the heading 1.0.0 i the changelog and copies them to RELEASE.md, which i can use for the release body.
I want the changelog be automaticly generated from the unreleased section. Your action does not support that?
so i have to use an action like this one prior to your's?

[CSchoel]

Yes, that is correct. In my own workflow, I apply all necessary changes to CHANGELOG.md manually.