MopeSWTP-SS21 / MopeSWTP

MIT License
1 stars 0 forks source link

Create a release #106

Open CSchoel opened 3 years ago

CSchoel commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 ☺️😎😵 githubrelease

manuEbg commented 3 years ago

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:

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

manuEbg commented 3 years ago

adding target_commitish fixed the issue regarding tagging the wrong commit... see https://github.com/softprops/action-gh-release/pull/76

CSchoel commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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