CI: Extend Github Release Target
PhilippvK opened this issue · comments
Features to be implemented:
- Pre-fill body of release-drafts with automatically generated changelog from commit messages (See https://github.com/marketplace/actions/get-a-changelog-between-two-references)
- Build MacOS App for Client with bundled JRE (DMG probably does only work on OSX, use IMG as an alternative on UNIX)
- Build Windows Installer with InnoSetup to bundle JRE with (only if really required, as it requires 32bit wine and does not support much distributions. Have a look at: https://github.com/TheBoegl/innosetup-docker)
- Make Version configuration consistens between artifacts. (Fill templates via Maven if needed)
I am already trying stuff out on the maven_dist branch.
Build Windows Installer with InnoSetup to bundle JRE with (only if really required, as it requires 32bit wine and does not support much distributions. Have a look at: https://github.com/TheBoegl/innosetup-docker)
It seems like Launch4j enables using an JRE located relative to the generated client.exe. Unfortunately it can NOT include the JRE right into the executable. The windows installer takes care of copying the jre to the directory where the EXE has been installed into.
I will give it a try because I think that the Client would be more accessible to others if installing Java 8 is not a requirement.
- [Docker] We could also add docker support for both client and server (Maybe separate issue?).
- [WINDOWS] https://stackoverflow.com/questions/49651902/how-to-get-the-jre-to-bundle-with-launch4j Maybe this could solve the problem with launch4j.
- [MacOS] I am not sure we need to include JRE in that one, I would consider userbase of macOS experienced enough to either have java already installed or know how to install it. They can also use docker without any problems so I would maybe solve MacOS problem with only .dmg (if it is working after the fix) and a docker image.
For the version consistency, I think we could migrate to version format like 2.1.0.0, which should be usable in all settings.
[Docker] We could also add docker support for both client and server (Maybe separate issue?).
Yes, separate issue please.
[WINDOWS] https://stackoverflow.com/questions/49651902/how-to-get-the-jre-to-bundle-with-launch4j Maybe this could solve the problem with launch4j.
Unfortunately not. It requires the jre to be placed relatively to the .exe. For this reason installers are recommended.
[MacOS] I am not sure we need to include JRE in that one, I would consider userbase of macOS experienced enough to either have java already installed or know how to install it.
I agree, Homebrew makes it very easy to install Java 8. However bundling the JRE is extremely easy (download JRE directory to a temporary directory and adding a single line to the <appbundle> section of the pom.xmp. The directory structure inside the Client.app will then include the JRE and use it by default. The DMG vs. IMG thing is just because I remember that I was not able to generate DMGs inside the travis container because of an non-Apple environment. If this issue does not exist anymore we can just use DMG.
For the version consistency, I think we could migrate to version format like 2.1.0.0, which should be usable in all settings.
I already wanted to mention this when I opened the issue bit somehow forgot to write this down. Currently 1.0.0 is hardcoded at some places and yes, your mentioned format should be used.
We can do this manually before release with mvn versions:set -DnewVersion=2.1.0.0 which actually sets it for all submodules as well. I will create PR which changes current master to this version.
I agree, Homebrew makes it very easy to install Java 8. However bundling the JRE is extremely easy (download JRE directory to a temporary directory and adding a single line to the
<appbundle>section of thepom.xmp. The directory structure inside theClient.appwill then include the JRE and use it by default. The DMG vs. IMG thing is just because I remember that I was not able to generate DMGs inside the travis container because of an non-Apple environment. If this issue does not exist anymore we can just use DMG.
Right now it generates DMG (and github actions also generates it) but I do now know if it works as I do not have a mac. I would very much like to avoid having a specific distribution branch with specific scripts as it creates a bunch of problems, so in my opinion, if we can do it all through maven it might be alright to bundle JRE with it, but we can't I would leave it as it is.
[WINDOWS] https://stackoverflow.com/questions/49651902/how-to-get-the-jre-to-bundle-with-launch4j Maybe this could solve the problem with launch4j.
Unfortunately not. It requires the jre to be placed relatively to the .exe. For this reason installers are recommended.
The same problem, if we can somehow do it all through maven I am ok with it, otherwise, I would swallow the fact that the .exe will require java if we the error they get clearly states that they need java 1.8. Since most of the potential players already played minigolf on Playforia, they already know about java a most likely have it installed anyway, so it shouldn't be that big of a deal.
If we somehow manage to download and bundle JRE with maven, however, we should think about binding these bundling actions to a different phase (maybe deploy?) so we don't download JRE with every mvn install.
One additional thing we could do is to create pre-release (2.1.0.0-BETA) to test if the release action works, to actually test it and to compare with this updated one.
The changelog in the Release notes are intended to help drafting the actual release notes by having the commit messages as an reference.