Closed gouttegd closed 7 months ago
@Clare72 Follow-up to our discussion on 24/01.
@matentzn FYI. This is an idea that I’d like to explore further and maybe generalize at the ODK level – e.g., allow an ontology maintainer to declare in the -odk.yaml
file a list of foreign ontologies that we want to remain consistent with, and have the ODK automatically generate an integration test like the one in this PR.
Here’s an example of a run (from a copy of the FBbt repo) when all three ontologies are consistent: https://github.com/gouttegd/fbbt/actions/runs/7680501702
And an example of a run when they are not (I deliberately restored a bogus mapping to create unsats): https://github.com/gouttegd/fbbt/actions/runs/7680755492
This PR adds a new, manually triggered GitHub Action workflow that attempts to:
The aim is to provide an easy way for any editor to quickly check that FBbt, Uberon, and CL are consistent with each other.
This is necessary because the standard test suite in each of those ontologies can only test whether each ontology is internally consistent after a change but cannot test whether that change creates inconsistencies when the ontology is merged with the other two. We could update the FBbt test suite to add a step in which we merge Uberon and CL, but that would create other problems: our test suite could fail at any time because of changes introduced in either Uberon or CL (unless Uberon and CL also update their test suites to do the same, to avoid ever introducing any change that could break FBbt+Uberon+CL), so it would no longer fulfill its role of testing the changes we want to introduce in FBbt.
If the test finds unsatisfiable classes, a file containing explanations for them (obtained through
robot explain
) will be made available to editors.Regardless of the presence of unsats, the file containing the merged ontology will also be made available to editors, should they wish to have a look at it.
(As an aside, this PR also updates the ODK-provided
qc.yml
file which contained out-of-date instructions to build the ontology. We do not use that file currently – our CI is done on Travis – but updating it will allow us to switch our QC from Travis to GitHub Actions anytime, should we wish to do so.)