I've discovered that one can use the file: "protocol" to manage
ImageJ update sites that are actually a git repository on the local
filesystem. This means that I can then have the update site pull
the changes from somewhere rather than have ImageJ push the changes
to the remote update site. This reduces the need for direct access to
the server with the overall goal being automating its deployment.
To make a new release of SIMcheck, an ImageJ plugin,
I do the following dance:
- build new release of SIMcheck;
- install it on a fresh local copy of Fiji;
- use the ImageJ updater to update the remote update site.
While most projects have their update site on sites.imagej.net, we host the SIMcheck update site on
one of our own servers — the Micron downloads site — together with
some mirrors for other ImageJ update sites. I like to own my
infrastructure and I like it distributed .
Anyway, I was never very happy with step 3 of this dance, namely the
part where ImageJ pushes changes directly to the public website. This
is in large part because I'm not happy with our the current setup. I
don't like having to access the downloads server to upload files. I
would much rather have them somewhere else and then configure the
server to fetch/mount the files from that somewhere else. I also want
to have the downloads site under version control and integrity checks.
My plan is to use git-annex
but there's always a lot of work to do and since infrastructure work
is never urgent it never gets done.
While restructuring our servers is not going to happen overnight, I'm
doing it one step at a time. For starters, I created a git repository
with the SIMcheck update site. The plan
now is to set up the downloads site to serve that git repository and
only have to specify the git hash to deploy on the ansible playbook.
But the ImageJ updater only makes changes on remote servers. From its
If you have an own server or web space with WebDAV, SFTP or SSH
access, you can create a directory in that web space and
initialize it as an update site, too.
I could set one of those services locally but seems too much work when
the things are already local. So despite the documentation I tried to
use file: as "host" and it worked just fine. This is how it looks
like on the ImageJ update site manager:
So my dance now is as follow:
- download a fresh copy of ImageJ;
- configure the updater with a SIMcheck update site that is the local
- install new version of SIMcheck;
- update the SIMcheck update site (local git clone) with the new
version with the ImageJ updater;
- commit and push the changes to the SIMcheck update site;
- pull the changes on the public server.
Which at the command line, roughly translate into:
$ wget https://downloads.imagej.net/fiji/latest/fiji-linux64.zip
$ unzip fiji-linux64.zip
$ cd Fiji.app
$ ./ImageJ-linux64 --update update
$ ./ImageJ-linux64 --update add-update-site SIMcheck-local \
$ ./ImageJ-linux64 --update update
$ mv PATH-TO-SIMCheck-REPO/target/SIMcheck_-1.3.jar plugins/
$ rm plugins/SIMcheck_-1.2.jar
$ ./ImageJ-linux64 --update upload \
--update-site SIMcheck-local \
$ cd ~/src/SIMcheck-update-site
$ git add plugins/SIMcheck_-1.3.jar-20210121203119
$ git add db.xml.gz
$ git commit -m "SIMcheck release 1.3"
I think it might be interesting to have something like this for
automating releases. An automation server can be triggered to build
new releases and push them to a git repository for each update site.
A site that serves those update sites can be configured to pull and
serve a specific commit for each update site.