Revert ODK image to latest used QC GH Action

[anitacaron]

Because some ongoing changes are not yet available in the latest ODK image, I updated the container to use the dev version, which is unstable.

Revert the commit 5f9733c

[gouttegd]

You realise that now that the {http://www.w3.org/2000/01/rdf-schema#seeAlso="https://meshb.nlm.nih.gov/record/ui?ui=D009619"} annotations from #3021 are in the uberon-edit file, any attempt to go back to the latest published ODK image will cause the test suite to fail for the same reason it was failing on #3021 in the first place – because the version of ROBOT in that image cannot cope with such annotations?

Either those annotations will have to be removed from the time being or we are stuck with a freaking development snapshot of the ODK until the next ODK release.

[matentzn]

@gouttegd lets move the discussion back home: owlcollab/oboformat#143 (comment)

The PR didn’t fix anything critical as far as I can tell – certainly nothing critical enough to warrant switching the entire ontology to an unstable development snapshot!

Lets be a bit more kind about the phrasing here: this PR did not switch the ontology to dev, it switched the QC checking to dev. Thats quite a bit less dramatic. If we would have switched the ontology to dev (update_repo), ok, I would have handed it my resignation now :P

But otherwise you are right of course. I fixed it now in #3029

[matentzn]

Should we create a document in the editors docs with nuggets of wisdom like this?

1. Never use unstable development snapshots
2. Never add unrelated changes to a PR

[gouttegd]

this PR did not switch the ontology to dev

Yes it did.

it switched the QC checking to dev.

And it accepted in the main ontology some annotations that cannot be processed with the stable ODK, which means that any attempt to build the ontology (be it for local testing or for a f*cking release) MUST use the development snapshot as well!

[matentzn]

And it accepted in the main ontology some annotations that cannot be processed with the stable ODK, which means that any attempt to build the ontology (be it for local testing or for a f*cking release) MUST use the development snapshot as well!

This is true.. I think we have heard the message now loud and clear!

[anitacaron]

Not everyone had a great weekend as I had.

This is under control if the release artefacts don't change anything different.

It's not the end of the world.

[gouttegd]

Not everyone had a great weekend as I had.

Indeed, since I spent my entire Friday evening debugging why my cleaning up PR suddenly failed after merging the master branch (which by then contained your PR #3021) into it. It should have been a last check just to confirm that everything was still good, and it turned into 4 hours of digging – in no small part due to the fact that there was nothing in the logs and the comments of the recently merged PRs to suggest what have happened and why.

I’m happy for you that you had a nice weekend after breaking Uberon without so much as a warning and then going offline for two days.

This is under control if the release artefacts don't change anything different.

If that’s really how you feel about it, that is a problem. No, everything’s not just perfectly fine just as long as the mess didn’t find its way into a release.

Hell, would you have even reverted the change before the next Uberon release, if the release was planned to happen
before the next stable ODK version is out? I suspect you would have had no qualms in making a release with the development snapshot – thereby potentially breaking any downstream ontology that uses Uberon unless they too switch to a development snapshot.

Seriously, pull off something like that again and I’ll withdraw from all Uberon maintenance. I’ll let the rest of the tech-support group fix the composite pipeline.