Use Github Actions for deployment

[tobiasdiez]

Use Github actions and jpackager for deployment. Rip circleci ❤️ . Rip install4j❤️

The following files are created and deployed to builds.jabref.org (and as github artifacts):

• for Windows: JabRef-5.0.0.msi (installer) and JabRef-portable-windows.zip (unzip & run)
• for Linux: jabRef-5.0.0-1_amd64.deb & jabRef-5.0.0-1_x64.rpm (packages) and JabRef-portable-linux.tar.gz (untar & run)
• for MacOS: JabRef-5.0-dev.dmg & JabRef-5.0-dev.pck (packages) and JabRef-portable-macos.tar.gz (untar & run)

Thus, we can provide an installer (or package) as well as a runable version for each OS.

---

• Change in CHANGELOG.md described
• Tests created for changes
• Manually tested changed features in running JabRef
• Screenshots added in PR description (for bigger UI changes)
• Ensured that the git commit message is a good one
• Check documentation status (Issue created for outdated help page at help.jabref.org?)

[koppor]

The gradle.yml seems like that we can move forward with V8 for citeproc (which requires different builds on different platforms): #3180

[koppor]

I set Java to 13.0.3 despite the fact that Java 14 was somehow desired. (Background on Java 14: https://jaxenter.de/java-14-update-news-85230). actions/setup-java supports zulu JDK only. Current distrubtions listed at https://static.azul.com/zulu/bin/.

JDK 14 could be installed using the "local file" feature: https://github.com/actions/setup-java#usage

[koppor]

Currently, the setup-java action does not support JavaFX: actions/setup-java#18

[koppor]

This PR depends on jpackage, which is currently under development. Possibly, it can replace install4j. For the current builds, we should stick to Install4J, because

• file association (.bib) unclear with jpackage
• jpackage needs more effort to get it running

[koppor]

jlink seems to be dependend on JDK 14: https://github.com/beryx/badass-jlink-plugin#badass-jlink-plugin

[Siedlerchr]

Related: https://help.github.com/en/articles/software-in-virtual-environments-for-github-actions

[koppor]

• Regarding the file names: I like JabRef_windows-x32_5_0-dev--snapshot--2019-09-12--githubActions--92c970011.XXX better than JabRef-5.0.1.XXX. A version string (such as 5.0.1) implies that there is ONE binary for that version (meaning, there is a 1:1 mapping to a binary). In the current implementation, it is a 1 to n mapping. For one version, there exist multiple binaries. This is IMHO not a good user experience... Would it be possible to use snapshot in the filenames. It is OK for me to drop the release date from the executable (and possibly also in the info screen)

Old screen

New screen

I can accept that we do not include any release date and commit id into the executable any more. I think, in the last years, we never checked for a commit id.

I think, I cannot accept that we do not have dev or SNAPSHOT in the filename.

[koppor]

With build/distribution folder I mean that if I as user unzip/untar the binary, I get the folder build. In this folder, there is the folder distribution. Then, I find JabRef. On windows, I find JabRef.exe. On Linux, I find bin/jabref.

I would have exepected JabRef/JabRef.exe, without the additional nesting in build/distribution.

[tobiasdiez]

The problem was that on Windows and Linux the version string had to be of the form 5.0.0.0 without additional "dev", "alpha" or whatever specification. I didn't bother changing the file names as I don't think its that important (we always refer the user to "build.jabref.org" with the words "please try out the development version..." so it that information is there from the context). But feel free to add "dev" to the files - shouldn't be that difficult as you can simply run any bash command you want. (I don't think we need to add the date (already present as file creation date), snapshot (duplication with dev) or the branch name & commit hash (not important for the user).)

The linux file folder structure of the tar should be fixed now.

That leaves the problem with the version string in the about dialog. I agree that it should contain all information. I didn't change anything fundamental in the script

jabref/build.gradle

Lines 511 to 542 in 701196a

	/*
	* Changes project.version to VERSION--DATE--GIT_HASH
	*/
	if (hasProperty('dev')) {
	String command = "git log --pretty=format:%cd--%h -n 1 --date=short"
	String commitInfo = ""
	if (OperatingSystem.current().isWindows()) {
	commitInfo = "cmd /c $command".execute().in.text
	} else {
	commitInfo = command.execute().in.text
	}
	// determine branch
	command = "git symbolic-ref -q --short HEAD"
	String branchName = ""
	if (OperatingSystem.current().isWindows()) {
	branchName = "cmd /c $command".execute().in.text
	} else {
	branchName = command.execute().in.text
	}
	// A newline is returned. Remove it. (trim())
	// In the context of github, the branch name could be something like "pull/277"
	// "/" is an illegal character. To be safe, all illegal filename characters are replaced by "_"
	// http://stackoverflow.com/a/15075907/873282 describes the used pattern.
	branchName = branchName.trim().replaceAll("[^a-zA-Z0-9.-]", "_")
	// hack string
	// first the date (%cd), then the branch name, and finally the commit id (%h)
	String infoString = commitInfo.substring(0, 10) + "--" + branchName + "--" + commitInfo.substring(12)
	project.version += "--" + infoString
	}

but I guess it is not called before

jabref/build.gradle

Line 281 in 701196a

expand(version: project.version,

. Proposal: instead of overwriting project.version (and having the additional versionThreeDots) make a function that creates a full version info and use this in the expansion of build.properties. But I don't have the gradle experience so I leave it to you to decide if that's the best approach.

[Siedlerchr]

The commit hash is important, to recognize if they use the correct master version.

[tobiasdiez]

Yes, its important in the about dialog (but not in the file name).

[koppor]

(Filename discussion)

Side note: In install4j, we kept the four dot version and changed the version internally only. With jpackage, however, this hack seems to stop working.

• date (already present as file creation date) --> If I download the file, the file gets a new date on my machine
• snapshot (duplication with dev) --> snapshot (more common in the java world) or dev (what we used until now) - both solutions are OK for me.
• commit hash (not important for the user) -- OK for me to have that in the about dialog only. -- We then accept that two files with the same filename (on different directories) lead to different versions (is OK as other tools like java.exe also do it)

So, OK for me to go with 5.0-dev as filename. In case we need 5.0.0-dev, we should adapt our program versioning to semantic versioning, too. Otherwise, it will be confusing for users, why only one dot is communicated, but the program version itself has two dots.

[koppor]

(Gradle discussion)

I need to google that. No clue.

[koppor]

Note to self: Current file list: http://builds.jabref.org/githubActions/

[tobiasdiez]

The version string in the about dialog is now working (in the end, the -Pdev=true switch was missing).
I'll merge this PR now to get early feedback from the users. Renaming the files can be done later.

[koppor]

We seem to switch to the fail-fast pattern... OK for me, but a different philosophy. The master branch still seems to be release-ready. 😅

[koppor]

I checked all builds at https://github.com/JabRef/jabref/runs/237858080. We do not seem to distribute a jar file anymore. Is this intended?

So we break the Gentoo distribution (refs #3380 (comment)). -- deep link to the ebuild script: https://github.com/jonasstein/jstein-overlay/blob/master/app-text/jabref-bin/jabref-bin-4.9999.ebuild

[tobiasdiez]

Yes, the jar file was not working - that was the main motivation for this PR in the first place. Thus, me merging quickly is more a fix-fast approach ;-)

The packages for Linux need to be changed indeed. But since we now provide rpm and deb packages, as well as a version where you only need to unpack it, the distribution should be more easy now.

[Siedlerchr]

There seems to be some problem with the jdk setup now.
https://github.com/JabRef/jabref/runs/240665291

[koppor]

3 hours later, in the master branch, everything was OK: https://github.com/JabRef/jabref/commit/3e1195d5d551014068a1731fa77f5f96b99a3be2/checks

Temporary issue?

[Siedlerchr]

The problem was in the jdk action, seems like they fixed it