Feature/release #123
Feature/release #123
Conversation
I commented out everything related to testing and added a build task. I hope this will speed up the action so I can have some fun
Serverlauncher should be singleton
|
I changed the base of the branch to |
| - name: Test with Gradle | ||
| run: ./gradlew test -i | ||
| - name: Build with Gradle | ||
| run: ./gradlew build -i |
There was a problem hiding this comment.
Why build and not test?
There was a problem hiding this comment.
This change means we will not get test results and code coverage anymore for each commit.
| - name: Grant execute permission for gradlew | ||
| run: chmod +x gradlew |
There was a problem hiding this comment.
I think I've said this before, but this should not be necessary if the file is checked into git with the correct permissions. Git is aware of file permissions.
| run: ./gradlew shadowClientJar shadowServerJar | ||
| - name: Add version from build.gradle to output | ||
| id: version | ||
| run: echo "::set-output name=version::$(./gradlew getVersion -q)" |
There was a problem hiding this comment.
I like the idea of getting the version from Gradle, but you didn't have to write a separate gradle task for this. This line of bash code would also do the trick:
./gradlew properties | grep version | sed "s/version: //"
Grep selects the line containing the version, the sed command replaces the string "version: " that is in front of the actual version number with the empty string.
| draft: false | ||
| prerelease: true |
There was a problem hiding this comment.
I would suggest doing this the other way around. A prerelease is for hotfixes and stuff that has to get out there before the "official" release is done. I think this script is more for generating regular releases, but I would set the draft state to true, so that you can review your release manually before it is made public to all users of the software.
| target_commitish: ${{github.sha}} #Get latest commit on this branch | ||
| draft: false | ||
| prerelease: true | ||
| tag_name: v${{ steps.version.outputs.version }} |
There was a problem hiding this comment.
This works for your setup, but is not fully correct. If you name your next tag v0.1.0 instead of 0.1.0, this would fail. Instead, you should use github.ref and remove the trailing refs/tag/ from the full ref, e.g. by using the parameter expansion of the shell like this: ${GITHUB_REF##*/}. In this case, all trailing patterns of the form */ found in the variable $GITHUB_REF are removed, leaving just the tag name (or any other remaining part of the ref that is not followed by a slash).
| body: | | ||
| Changes in this Release | ||
| - separating build and release |
There was a problem hiding this comment.
I am sure you are aware of that, but this should be replaced by a dynamic script generating the release body from the change log or any other source on the file system. Hard-coding the release notes in the Gradle script is a little clunky.
| @@ -4,7 +4,7 @@ plugins { | |||
| } | |||
|
|
|||
| group 'thm.mope.lsp' | |||
| version '0.1.0' | |||
| version '0.0.9-test3' | |||
There was a problem hiding this comment.
Just a small note, but be careful with downgrading version numbers. This will confuse any package manager, because the assumptions with version numbers is always that higher versions are more up to date than lower ones. Some package managers therefore only allow you to publish versions of your software that are a direct upgrade from an already existing version. So if you have, for example 0.0.9 and 0.1.0, you can upload versions 0.0.10, 0.1.1, 0.2.0, or 1.0.0, but these are your only options. There is no harm in already sticking to this scheme during initial development.
I created this pull request prematurely in order to be able to provide a comprehensive code review. This branch is still work in progress.