automate updating ODK in some way

[shawntanzk]

Possible solutions:

• Is there a possibility of automating update ODK PR, perhaps using GH actions? Is this a good idea?
• Setting up something that warns users when using an ODK command if ODK is out of date?
• If not custom makefile, automate it?

[shawntanzk]

First step: extend run.sh with a docker lookup to check if there is a newer version than the one installed

https://github.com/INCATools/ontology-development-kit/blob/master/template/src/ontology/run.sh.jinja2 <- add the check to this

Have to check Docker for support - https://gist.github.com/byrnedo/9b2078c191360c681f85cebb2187d66f

Create documentation on steps for people to follow - create ticket on obook

[gouttegd]

The first step mentioned above may not be as easy as initially thought, as it doesn’t seem possible to check the Docker registry for the list of available images and image tags without being authenticated with a DockerHub account. All API endpoints seem to require authentication:

$ wget https://index.docker.io/v2/obolibrary/odkfull/tags/list
HTTP request sent, awaiting response... 401 Unauthorized
$ wget http://hub.docker.com/v2/namespaces/obolibrary/repositories/obolibrary/images
HTTP request sent, awaiting response... 401 Unauthorized

We can’t request all users of the ODK to have a DockerHub account just so that they can check whether they have the latest image…

[matentzn]

Ihhhhhhhhh oh noooo! This puts our plans down the drain. Now this is terrible: What about simply adding an echo to the end of run.sh:

echo "Your ODK does not automatically update. See here whether a new version is available: https://hub.docker.com/r/obolibrary/odkfull/tags. To update your ODK, you should run "docker pull obolibrary/odkfull".

Maybe to not pollute output too much, add a check:

if [ "prepare_release" or "update_repo" in $1]:  
     echo ...

Maybe someone has a better idea..

[gouttegd]

I was going to discuss that at the next TechSupport call, but what I am envisioning for now is a somewhat simpler system in which we do not rely on Docker Hub.

Basically:

• we (ODK developers) put a file somewhere on a server containing the version number of the latest release (this could be on GitHub, or on any other server that we somehow control);
• the run.sh script fetches that file, reads the version number from it, and compares that with the version number of the currently installed ODK; if it‘s different, print the “you should update” message.

This would be slightly more cumbersome for us as we would need to remember to update the file containing the version number (whereas using Docker Hub would dispense us of having to do anything), but it should work.

Possible bonus: depending on where we put the version file, if it is on a server we control enough to have access to the logs, we could then get some measures of 1) how many different IP addresses are trying to use the ODK; 2) how often they run the run.sh script. (However if we do that I feel that we have to provide users with a way to opt out.)

[matentzn]

Brilliant! I like it very much!

[matentzn]

(note it creates a network dependency, so we should help out people that want to run ODK without access to the internet)

[gouttegd]

Well we were always going to be dependent on network connectivity anyway, no matter how we do the version check (we have to look somewhere to find out what the latest version is, whether we look on Docker Hub or anywhere else).

But agree, the version check should fail gracefully (and with a very short timeout) in case of network problems (including complete absence of network connectivity).

[shawntanzk]

If cmd includes prepare_release - echo a string in run.sh in Template/src/ontology/run.sh.jinja2 in ODK "Do not forget to update your ODK, for instructions on how to do this, see: [LINK] " @matentzn to write up an obook how to on how to do this @ubyndr to implement

[anitacaron]

Related to the last comment, this was done in the PR https://github.com/INCATools/ontology-development-kit/pull/594, and it's available since version 1.3.1 (Release Notes).