[matentzn]

Adds an id_preservation job to CI that fails if a PR loses an ENVO ID. This is how #1675 happened: #1631 dropped 145 classes and nobody noticed in review because GitHub hides large diffs.

How it works:

• On every PR, the job checks out the base commit next to the PR merge result and runs make check-lost-ids ID_CHECK_BASE=....
• For each side it collects every ENVO IRI that has an rdfs:label in ENVO's own sources: envo-edit.owl without its imports, the pattern modules and the NMDC template. These are the same files that go into envo-base.owl.
• Any term labelled on base but not on head fails the job, and the log lists each lost ID with its label.

I check for labels rather than declarations because ROBOT adds a type to anything still referenced, so a stripped class that's still used as a parent would otherwise slip through. Obsoleting a term passes (it keeps its IRI and its "obsolete …" label). So does moving a term between the edit file and a module, or dropping foreign declarations. Terms that appear only in import modules don't count. There's no allowlist: ENVO IDs don't get deleted, they get obsoleted.

Tested locally in odkfull:v1.6:

• 2025-08-19 release from 2025-06-02-RC2 #1631 replayed (base f945fa9, head 156dd8a): fails, 160 terms lost. That's the 137 classes from Restore 145 classes removed without obsoletion in the 2025-08-19 release #1675, the 17 NMDC value-set annotation properties from NMDC value sets disappeared from 2025-08-19 #1642 and 6 ecoregion individuals.
• pre-Restore the edit file to its state before the 2025-08-19 release #1676 master to the Restore the edit file to its state before the 2025-08-19 release #1676 head: passes (4366 → 4526 labelled terms).
• make check-lost-ids the other way round (Restore the edit file to its state before the 2025-08-19 release #1676 head as base, pre-Restore the edit file to its state before the 2025-08-19 release #1676 master as head): fails with the same 160, exit code 1.

#1677 removes 8 unlabelled ENVO declarations and would pass, because the check only tracks labelled terms.

Once this is merged, someone with admin rights needs to make id_preservation a required status check in branch protection. Otherwise it only warns.

Part of #1675

[turbomam]

Thanks @nico. I support this PR.

I reran the check from this branch in odkfull:v1.6 against three pairs of commits and got what the description claims:

• f945fa9 to 156dd8a fails with 160 lost terms (4,526 to 4,366)
• f3979d8 to c6730c4, the subsets obsoletion, passes with 4,526 on both sides
• c6730c4 to 68dab49, the wetland biome, passes with 4,526 to 4,527.

The skip for a file missing on one side also worked for the template that c6730c4 removed.

I would liek to suggest on change before merging: the workflow's pull_request trigger is filtered to branches: [ master ], so a pull request whose base is another branch never runs the job. The wetland biome was in that position until this morning. Dropping the filter under pull_request closes the gap.

Note that master has no branch protection at all today (the branches/master/protection endpoint returns 404), so until a rule requires pull requests and this job, a direct push to master skips it.

[matentzn]

@turbomam agreed on the pull_request filter, I'll drop it. That also gets ontology_qc running on stacked PRs, so you won't need to retarget to master to get CI. Each layer gets checked against its own base, which is what we want.

On protection: master does have a rule. The endpoint just 404s if you don't have admin on the repo. It requires PRs and an up-to-date ontology_qc, plus resolved conversations. I'll add id_preservation as a required check once this is merged.

[turbomam]

Thanks @matentzn. I agree, I was wrong about master having no branch protection. I checked with the GitHub API's branch protection endpoint for master, and it returned a 404 because I don't have admin on this repo.

Thanks for adding the loss of IDs check. I'll probably add something like this to other projects I work on.