feat: set up new github workflow for only ontologies that have changed

[joyceyan]

Reason for Change

• now that we go through all of the ancestors in NCBITaxon, it takes about two hours for the generate_all_ontology.yml job to wrap up, which is.. quite long if we just want to do simple things like bump versions of smaller ontology graphs

note: i did try to put all of this into one workflow, but i couldn't figure out how to check if only ontology_info.json was updated and the other files were not updated. there potentially is a way for this to be done so that if we update ontology_info.json and all_ontology_generator.py, then we don't have to run both workflows. that being said, i do think that there are some benefits to having it be a separate workflow entirely. it's immediately clear to the person writing the PR which version of the script we're executing since we would start the "Updates to Diff'd Ontology Files" job instead of the "Updates to Ontology Files" job

Changes

• creates a new GHA workflow generate_diff_ontology so that we only download / process ontologies that have changed since the last run by executing the script with a --diff flag if the only file we've changed is ontology_info.json
• the latest ontologies we processed are now stored in latest_ontology_info.json
• if any changes are made to ontology_info_schema.json, all_ontology_schema.json, or all_ontology_generator.py, then we re-generate all ontology files without the --diff flag by executing the old generate_all_ontology workflow

Testing steps

• i ran the script locally with the download/parsing commented out to verify that we write to latest_ontology_info.json correctly
• i also fiddled around locally with changes to latest_ontology_info.json to verify that we're only picking up diffed changes
• going to be setting up PR's against this branch to verify the GHA performs as expected:
  • this PR only bumps the CL version in ontology_info.json, and only the generate_diff_ontology workflow is executed. the ontology-assets/latest_ontology_info.json file was also automatically generated and added by the workflow
  • this PR updates the all ontology generator script, so it executes the original workflow which re-generates everything

[codecov]

Codecov Report

Attention: Patch coverage is 15.78947% with 16 lines in your changes missing coverage. Please review.

Project coverage is 88.56%. Comparing base (0ac2219) to head (faa7659).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...ols/ontology-builder/src/all_ontology_generator.py	11.11%	16 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #264      +/-   ##
==========================================
- Coverage   89.27%   88.56%   -0.71%     
==========================================
  Files          19       19              
  Lines        1343     1356      +13     
  Branches      121      122       +1     
==========================================
+ Hits         1199     1201       +2     
- Misses        124      135      +11     
  Partials       20       20              

Flag	Coverage Δ
unittests	88.56% <15.78%> (-0.71%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nayib-jose-gloria]

do we know what happens if we update both ontology_info and all_ontology_generator.py? do we need to add some sort of "if ontology_info is updated but not all_ontology_generator" conditional logic here?

[joyceyan]

if both the files are updated, then both workflows will be executed. it's not ideal, but i spent 1-2 hours trying to prevent that from happening and i couldn't figure out how to do it. i'm also not super well versed in how to write GHA workflows with conditional logic, so it certainly could be possible with more investigative effort.

what i was thinking for now is that if you do enter this edge case, the developer writing the PR can just cancel the workflow that's not needed, or just allow both to run. allowing both jobs to run shouldn't cause any issues in the expected generated ontology assets, it would just waste some time and some GHA resources. if that ends up being too annoying, we can patch this edge case as a follow up.

since trying to handle this edge case took up about half the total time i spent on this, i figured it's still better to get this change out first so we see an immediate benefit to lower runtime for ~most PR's generating ontology assets--especially since this was already annoying me this week while i was working on adding in the CL terms into EFO for perturbations.

[nayib-jose-gloria]

sounds good, thanks for looking into it

[nayib-jose-gloria]

nice, thank you! left a note about one github workflow edge case

[nayib-jose-gloria]

change looks good, optionally mind adding a TODO or jira ticket or something to document that we're aware of the double update edge case?