fiji / fiji-builds

Downloadable Fiji bundles

This repository creates the Fiji downloadable bundles available from:

• https://downloads.imagej.net/fiji/archive/
• https://downloads.imagej.net/fiji/latest/

fiji-builds's Issues

Switch deployment from SSH to WebDAV

This repository's CI now runs on GitHub Actions. But those IP ranges are not on the allowlist on our hardware firewall, and the job cannot upload the bundles:

debug1: Connecting to downloads.imagej.net [144.92.48.183] port 22.
debug1: connect to address 144.92.48.183 port 22: Connection timed out
ssh: connect to host downloads.imagej.net port 22: Connection timed out
lost connection

Unfortunately, there are more than 1600 IPs:

$ curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/meta | grep -A9999 '"actions"' | grep -B9999 '^  ],$' | grep '[0-9]\+\.[0-9]\+\.[0-9]\+' | wc -l
    1654

So it's time to migrate away from uploading the Fiji application bundles via SSH. It's a dangerous protocol anyway due to remote execution concerns. We can switch to WebDAV and upload the bundles that way instead.

Windows version of Fiji does not ship javac.exe

Trying to compile a Java program using the Fiji embedded version of Java on a recent installation (zulu8.60.0.21-ca-fx-jdk8.0.322-win_x64; 172MB in size), I noticed it only has a jre folder, no javac.exe. Not sure how that happened, but we need to be shipping a full JDK, not just a JRE, for every platform.

Decide whether to update the Fiji Package Maker, or move away from it

Right now, Fiji gets wrapped up by the good old Fiji Package Maker plugin. That plugin hasn't been updated in a long time; in particular, it doesn't know about jars/<platform> folders for platform-specific JARs. We should consider how best to pack up the Fiji bundles going forward:

• Update fiji.packaging.Packager to understand jars/<platform> and fix any other shortcomings?
• Ditch the use of Fiji_Package_Maker in favor of shell-script-based globs or similar?
• Some other way?

Reenable the CI

The cache config in .github-disabled does not work. Figure out why, fix it, and re-enable the CI.

Improvement: use of "latest" softlink

Currently we're uploading a new build to "latest" and and backing up the old one to "archive/". Modify script to directly upload to archive/ and update soft link "latest" to point there.

Move to GitHub actions

The Travis CI cache is broken. It does not recognize that a cache exists and thus does not allow clearing it.