GitHub action for automatizing shup release with openWebStart configu…

[LaurentPV]

Creation of shup.jnlp configuration file for OpenWebStart that points towards .jnlp file and .jar archive located in releases/tag/${project.version} of git repository (when git release action will be completed). In this .jnlp file we inject the value associated with project.version in shanoir-uploader pom.xml so that when releasing a new version we only need to modify the version in pom.xml

Adding in shanoir-uploader pom.xml the copy of .jnlp file from ${project.basedir} to ${project.build.directory}, we set the maven antrun plugin copies as "prepare-package" phase to be sure that all files are available in /target directory for next steps.
Adding a maven replacer plugin step to inject the ${project.version} value of the pom.xml file into the .jnlp file located in /target directory

Creation of release_shup.yml file in .github/workflows to configure the GitHub action of releasing shanoir-uploader with the right project.version value and the .jnlp and .jar files in the same release every time there is a push onto the master branch concerning the content of /shanoir-uploader directory.

[LaurentPV]

The build will fail because the maven jar signer will need a keystore to do its job.
We (@michaelkain ) will need to do the following steps in order to test the release :

1. create a java keystore that contains the same Institution name as the vendor name in the .jnlp file (I put "Empenn Team - Inria").
2. Add the maven repo certificate to that keystore
3. Encode in base64 this keystore
4. create the GitHub repository secrets variable KEYSTORE_BASE64 and copy as value the content of the encoded keystore
5. create the secrets KEYSTORE_PASS and KEY_ALIAS with as values the password and alias specified when created the keystore

For now as tested on a local branch :

• when a push or pull request concerns any shanoir-uploader/ file on the master branch, it launches the GitHub action release_shup that create the release with the version specified in pom.xml and add the jnlp file inside the release.
• I added a jar signing step in the shanoir uploader pom.xml that signs the jar with the keystore stored in GitHub secrets. To allow a local maven build this step depends on the property "skipSigning" (true by default).
• the jnlp file contains the url of latest release on GitHub repository, so that once this file is downloaded by user it can always be used and still get the latest release of Shanoir Uploader. The user only has to download and install OWS, download the jnlp file and double click on it and Shanoir uploader launches.

2 minor issues :

• for now the jnlp file has a default OWS icon, I tried to change it to a Shanoir icon (that's why I added one with good format in shanoir-uploader resources) but on Mac OS it doesn't work yet.
• I didn't find where the jar name containing the value is set. As we cannot use a wildcard in the xml (= jnlp) file to replace any version by a * for example in the jar name (so that the jnlp file is never obsolete and always gets the latest release), I wanted to delete the version from the jar name as now we have GitHub tags with the version for each release. Tell me if it's ok with you.

[michaelkain]

Hi @LaurentPV, I wonder, if we should do something on each pull request or only, when something goes on master? I think even with each new integration into master, we will not release a new version of ShUp. I think it would be interesting for each push into master to create a new "timestamp" in RELEASE_DATE on ShUpConfig.
I think the process of having a new version, as today the tags for the prod release by Anthony are driven by a human decision, not by an integration on master. With kind regards, Michael

[LaurentPV]

Ok, I will add a new commit modifying the RELEASE_DATE constant with the timestamp of the push on master branch.
Do you mean that the tag of the release should be the release_date instead of the release_version ?
It seems weird not to have the tag of a version linked to a release but in the same time it would be more convenient because it assures the uniqueness of each release tag. For now if you forget to modify the version in the pom.xml before pushing into master the release will fail because the previous release exists already.