Make development version/snapshots available in choco community repository

[kmindi]

There should be a package for development/beta builds at chocolatey community repository

[Siedlerchr]

All development builds can be accessed here: http://builds.jabref.org/

No one of us is officially maintaining the chocolatey build.
@koppor probably has more infos

[koppor]

Chocolatey package is maintained by @OlafHaag. Please ask for that feature at https://github.com/OlafHaag/chocolatey-packages/ Refs OlafHaag/chocolatey-packages#6

[OlafHaag]

BTW: If anyone else wants to become a maintainer for that package that's totally fine with me.

[Siedlerchr]

I discovered a GitHub Action which could be useful to automatically deploy to chocolatey:
https://github.com/crazy-max/ghaction-chocolatey

[OlafHaag]

I discovered a GitHub Action which could be useful to automatically deploy to chocolatey:
https://github.com/crazy-max/ghaction-chocolatey

Nice catch, but for now I'll stick with my appveyor-AU module setup for automatic updates. Because it's less work for me I only look for releases on the releases GH page. Since the 5.0-alpha is listed there, it is available in choco with choco install jabref --pre.

[koppor]

development build == build available at https://builds.jabref.org/master (updated at least once a week)

beta build == build released at GitHub releases.

Since our master branch is intended to be usable (like Debian/unstable 😅), I think, it would be good to make development builds available, too. I know, this complicates things. However, the filenames will not change (at least for the portable version).

[tobiasdiez]

@OlafHaag I had a look at the chocolatey documentation and was a bit overloaded with information and different package options/ways to manage them. Since you appear to be an expert when it comes to chocolatey, I hope you can help us here. In the case of our dev version, we want to have a script that publishes the current installer (msi file) to chocolatey. Since we would run the script as part of the github action after a merge of a PR, we know that the code changed and the script has all necessary information (e.g. version, url to msi). So I guess we don't need the automatic update infrastructure, right? What would be the easiest way to create (and submit) a chocolatey package in this case?

As choco does not provide a nightly switch, I guess it is best to create a new package jabref-dev for the development version (similar to firefox-dev).

[OlafHaag]

I don't know about the expert status, but I'll try to help where I can.
Actually, chocolatey discourages the creation of a separate dev-stream for a software. It has the --pre switch to install pre-release versions. That should work as long as the choco packages have according versions for the dev builds. Looking at this issue I don't think choco supports Semantic Versioning 2.0.0 just yet (e.g. where you could do 5.0.0-alpha.1), but 5.0.0-alpha-20190930 would also work. Precedence is determined by lexicographic ASCII sort order. It's encouraged that the package version follows the software version.

I haven't had your case yet, because I'm not the vendor of any of the software I maintain in the chocolatey community repository. I found it easiest to use the AU Powershell module for my situation.
The packaging requires basically only 2 files: the nuspec and the tools\chocolateyInstall.ps1.
You can either replace certain strings using regex or write the file fom scratch. In the nuspec you would replace the version and the release notes, in the install script the URLs and checksums (and fileType if you have an MSI instead of an EXE).
The AU module makes this easy as you can see below in an example.

function global:au_SearchReplace {
    @{
        "tools\chocolateyInstall.ps1" = @{
            "(?i)(^\s*packageName\s*=\s*)('.*')" = "`$1'$($Latest.PackageName)'"
            "(?i)(^\s*fileType\s*=\s*)('.*')" = "`$1'$($Latest.FileType)'"
            "(?i)(^\s*url\s*=\s*)('.*')"        = "`$1'$($Latest.URL32)'"
            "(?i)(^\s*url64bit\s*=\s*)('.*')"   = "`$1'$($Latest.URL64)'"
            "(?i)(^\s*checksum\s*=\s*)('.*')"   = "`$1'$($Latest.Checksum32)'"
            "(?i)(^\s*checksum64\s*=\s*)('.*')" = "`$1'$($Latest.Checksum64)'"
        }

        "$($Latest.PackageName).nuspec" = @{
            "(\<releaseNotes\>).*?(\</releaseNotes\>)" = "`${1}$($Latest.ReleaseNotes)`$2"
        }
    }
}

I have it all run online online on appveyor on a CRON job. But for simple string replacement you wouldn't need any of that, I guess.

If you have your nuspec and chocolateyInstall.ps1 files ready, the only thing left to do is choco pack and choco push. You would need your choco API key and the status of a maintainer of the package in order to successfully push.
So, the aforementioned chocolatey GH-action actually sounds like the way to go.

When the names/URLs of the install files don't change and aren't avaible anymore with each new build, all the pre-release packages will be broken on a daily basis if they just link to the same URL and the hashes don't match. Alternatively, you could package the MSI or Zip with the choco package. Then all older versions would be still available on choco.

PS: I didn't even know about the portable version. We should add that. There would then be a virtual package jabref, that really doesn't do much except having a jabref.install package as a dependency, and a separate jabref.portable package.

[koppor]

@OlafHaag If we trigger the build directly after the upload to builds.jabref.org, the mismatched hashes should be an issue for 10 minutes at maximum. -- OK, we could try to keep the version of the last day (having the date in the filename) and always publish that version.

[OlafHaag]

Almost forgot: Between packaging and pushing the choco package, it should be tested to install successfully. This would have to be part of the GH action.

[OlafHaag]

To become maintainers, just contact the Site Admins on the jabref chocolatey package site. Short instruction: I want to take over/help with package maintenance for my software.

[tobiasdiez]

@OlafHaag thanks for the guideline. I started working on a first version in #5378 and in principle its working now. The AU is indeed not required as the msi url stays (relatively) constant and we can calculate the checksum on the fly. One question: you said that it would preferable to publish the development version as the same package on chocolatey just with a different version string. But if I understand it correctly, then there is now way to distinguish the released alpha from the dev version. Thus always the dev version is installed if I use choco install jabref -pre, right? That's probably not what we want.

Btw, the portable version works but doesn't come with the usual nice bells and whistles like desktop shortcut, file association, etc. Thus I guess the msi installer is still the preferred form of installation.

[OlafHaag]

Good to hear!
Yes, the alpha as well as the dev version will be marked as prereleases by choco. You'd have to distinguish them in the description, so the user can decide which to install. You can always install a specific version by specifying it, e.g. choco install jabref --version 5.0-alpha-20190828 (maybe one has to append --pre still, even when specifying the exact version).
But doing cup jabref --pre would update to the latest dev-version.
For the dev builds, you could probably add a disclaimer and a link to the released alpha package in the description to make it transparent to the user. People using the --pre switch should expect to get a possibly unstable version.

Only when one tries to install a specific version for which the installer isn't matching the hashes anymore, because the file was updated in the meantime, but still has the same name, the package will be broken. Or if the installer isn't reachable anymore.

[tobiasdiez]

There is some initial progress at #5378, but I don't have time right now to work on this further. @anyone fell free to reuse it as a basis for your own PR.

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[koppor]

We are currently trying to focus on other things. 🔥
We will come back later to this topic, therefore closing adding freeze label and closing the issue for now.