[turbomam]

The src and base ROBOT reports run without imports, so problems that come in through imports never appear in CI. This adds a Makefile target reports/envo-closure-robot-report.tsv, which runs robot merge --collapse-import-closure true then report --fail-on NONE, and a closure_report target that prints counts by level. qc.yml runs make closure_report after the existing checks. It records the counts and leaves the build result as it was. The report stays out of all_reports, so releases are unchanged. Once the ERROR count reaches 0 the step can switch to failing on ERROR. The PR below makes the src and base reports fail on ERROR for ENVO's own terms.

In obolibrary/odkfull:v1.6 on master on 2026-11-02, make closure_report exits 0 and prints 60 ERROR, 1736 WARN and 401 INFO.

Related:

• Limit the src and base ROBOT reports to ENVO's own terms and fail them on ERROR #1696

Part of:

• The ROBOT reports in CI skip the import closure, so problems from imports go unreported #1701

[Copilot]

🟡 Changes recommended

The closure report can show stale counts after imported ontologies or modules change because its Make target depends only on envo-edit.owl.

1 open issue

• Report ignores imported ontology and module changes · New

What changed in this PR

Adds import-closure reporting to ENVO’s CI, complementing the existing reports by exposing problems introduced through imported ontologies.

Changes:

• Adds a ROBOT report that merges the full import closure without failing on reported violations.
• Adds closure_report to print counts by severity and runs it after existing CI checks.
• Keeps the new report outside all_reports, leaving release reporting unchanged.

File	Description
src/​envo/​Makefile	Adds the import-closure report and severity-count target.
.github/​workflows/​qc.yml	Runs the closure report after the existing ontology checks.

_{Review effort: Balanced}

[pbuttigieg]

I get the direction, but shouldn't the fail be during the actual build rather than the reporting phase? I would rather that the reporting doesn't fail on error, so we can look them up.

For sure, there should be a build error if the merge doesn't work

[matentzn]

I dont think this is needed. No other ontology does this: QC on imported ontologies is a tar pit, and your test is not even failing - no one will read the CI log ever, so there is no point to add it there. The makefile additions are harmless by themselves, but, as I said - not sure if this is really required

[turbomam]

@pbuttigieg I see you still have eyeballs. I am taking @matentzn 's guidance but that doesn't mean you shouldn't open new more isolated issues. That doesn't mean that I would necessarily be the one developing them :-)

[pbuttigieg]

@pbuttigieg I see you still have eyeballs. I am taking @matentzn 's guidance but that doesn't mean you shouldn't open new more isolated issues. That doesn't mean that I would necessarily be the one developing them :-)

Just to indicate I saw @matentzn's input