ODKRunner 0.4.1

Changes since version 0.4.1:

• Add a new setup-script mode to facilitate the creation of a native ODK environment.

Calling the runner as follows:

$ odkrun setup-script

will produce (on the standard output) a shell script that can be used to automatically initialize a native ODK environment, which can then be invoked with odkrun -n.

(Highly experimental, GNU/Linux and macOS only.)

ODKRunner 0.4.0

Changes since version 0.3.0:

• Allow the use of native ODK environments as created by the odk install command of the new ODK-Core project.
• Add the --assumed-odk-repository option.
• Fix incorrect detection of OAKLib's cache directory.

ODKRunner 0.3.0

Changes since version 0.2.1:

• The runner can be configured through ODK_ environment variables as an alternative to a run.sh.conf file (not recommended, but for compatibility with the ODK-generated run.sh script).
• The max memory setting for Java applications can now be explicitly be set on the command line through the -m, --java-mem option.
  • That option takes precedence over any -Xmx option passed through ODK_JAVA_OPTS.
  • The --java-mem value should be of the form Xm, Xg, or X%, to set the maximal amount of memory to X megabytes, X gigabytes, or X percent of the available memory, respectively.
  • The default behaviour, when that option is not used, is still to use 90% of the total memory available to the backend.
• If the environment contains typical variables used for proxy configuration (http_proxy, https_proxy, no_proxy, or their uppercase equivalents), the proxy settings are automatically passed to the container.

ODKRunner 0.2.1

Changes since version 0.2.0:

• If the image name (given to the --image option on the command line, or the ODK_IMAGE option in a run.sh.conf file) is unqualified, the obolibrary/ qualifier is automatically prepended (so, --image odklite is equivalent to --image obolibrary/odklite).
• Support for sharing the host’s local OAK cache directory with the container:
  • If the --oak-cache (-k) option is set to user, the user’s own OAK cache directory (by default ~/.data/oaklib, but it may be located elsewhere depending on the local Pystow configuration) is bound to /home/odkuser/.data/oaklib, so that any OAK command invoked within the container will benefit from the user’s cache.
  • If the option is set to repo, the variable OAKLIB_HOME will be set to /work/src/ontology/tmp/oaklib and exported into the container’s environment, so that any OAK command invoked within the container will use the tmp/oaklib directory as its cache. This is only effective when odkrun is started from within the src/ontology directory of an ODK repository; otherwise the option is ignored.
  • If the option is set to any other value, the value is interpreted as a path to an arbitrary directory on the host, which is bound to /home/odkuser/.data/oaklib within the container (so, --oak-cache user is in fact equivalent to --oak-cache ~/.data/oaklib, assuming the OAK cache is in its default location).
  • The -K option is a shorthand for --oak-cache user.
  • The option ODK_SHARE_OAK_CACHE, if found within a run.sh.conf file, is interpreted in the same way as the --oak-cache CLI option.

ODKRunner 0.2.0

Changes since version 0.1.0:

• The runner now supports the run.sh.conf configuration file also used by the ODK-generated run.sh wrapper script. If such a file is found in the current working directory, the runner will attempt to parse it and set the corresponding options prior to invoking the container.

ODK Runner 0.1.0

Initial release of the experimental “ODK Runner”, a binary runner to execute commands within a ODK container.