-
Notifications
You must be signed in to change notification settings - Fork 33
Oort Continuous Build
Continuous integration (CI) refers to a continuous process of quality control, as opposed to the traditional practice of applying quality control after releases. Whilst traditionally used used in software development, the same principles apply to ontology development - Oort is in a sense an "ontology compiler".
Oort can be used with a CI environment such as Hudson or Jenkins
Oort can be hooked up to any CI environment. In practice Hudson/Jenkins is a popular choice for software, and we have practical experience here. Having a web based CI environment has a number of advantages.
In 2011 the Hudson project split into two - Hudson and Jenkins. From a practical perspective these are fairly similar. We have more experience of Jenkins.
Jenkins is very easy to install. It is also easy to set up a job for every ontology you want to build (after doing one, just clone this for the others).
Things are much easier if you switch from CVS to a system like SVN (although CVS can be used). You will probably want to set your jobs to "poll SCM", which means that SVN server is polled continuously and a build is set in motion once something changes.
The job shell command typically consists of just something like:
export PATH="$PATH:/path/to/oort"
ontology-release-runner --simple --allow-overwrite --reasoner elk MY-ONT.obo
But you are free to add extra QC checks here (e.g. each ontology might have their own ad-hoc scripts for checking)
Your build artefacts might look like this:
**.obo,**.owl,**.txt,subsets/**.obo,subsets/*.owl
Access to the OBO Foundry Ontology CI service available on request
The idea of applying CI techniques to ontologies using Hudson was first implemented by Sebastian Bauer of the Human Phenotype Ontology at Charite.