Commit Predictions File with Git Hash Link, Remove Artifact Upload

[nagutm]

This PR refactors the GitHub Actions workflow for the paper ranking script to ensure the predictions file is committed directly to the repository. The following changes were made:

1. Removed Artifact Upload Step:

• The actions/upload-artifact step in the workflow is currently used to store files generated during the workflow. These artifacts are then available for download in the GitHub Actions interface under the "Artifacts" section for that workflow run.
• The addition of the commit and push step below makes this step unnecessary and was removed to avoid redundant storage.

2. Added Commit and Push Step:

• Introduced a new step to commit and push the predictions file directly to the exports/analyses/paper_ranking/ directory in the repository.
• This ensures that the predictions file is saved in the repository for future use if necessary.

Testing via a forked repository successfully showed that the predictions file was saved to the correct directory once the workflow run was complete.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 46.27%. Comparing base (8950e70) to head (b495c04).
Report is 274 commits behind head on main.

Files with missing lines	Patch %	Lines
src/bioregistry/analysis/paper_ranking.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1350      +/-   ##
==========================================
+ Coverage   42.51%   46.27%   +3.75%     
==========================================
  Files         117      118       +1     
  Lines        8327     8301      -26     
  Branches     1963     1357     -606     
==========================================
+ Hits         3540     3841     +301     
+ Misses       4582     4275     -307     
+ Partials      205      185      -20     

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

[cthoyt]

I would suggest appending to the existing predictions file, rather than creating new ones each time. If you need to keep track of date provenance for this, then you could add a new column for the publication date

[bgyori]

I would suggest appending to the existing predictions file, rather than creating new ones each time. If you need to keep track of date provenance for this, then you could add a new column for the publication date

Here is why we designed this process as it is currently:

• The ranking is incremental in that it combines new papers with uncurated past papers to re-rank all papers. So it's not a simple append operation. This ensures that uncurated past papers that are highly ranked can still be surfaced.
• In addition, we wanted to ensure that each month's comment posting new ranking results points to a specific file that is associated with that comment, even if newer comments/rankings have been posted since.

I do have an idea that could work and serve as a better solution:

• We could have a single version controlled ranking file
• Each time the ranking is done, the ranking file is overwritten with the new rankings in a github-actions commit
• The comment posted on the issue doesn't simply add a link to this file from the main branch but uses the github-actions commit's hash (the one added in the previous step) in the direct link to the file. This ensures that the link will continue to exist later while also being reproducibly associated with the current issue comment.

Should we try this?

[cthoyt]

I think using a commit hash is a great idea.

The action that updates this file can also periodically clean out old predictions that have been either curated or incorporated into the bioregistry.json file

[bgyori]

@nagutm before we wrap this up: is adding the file exports/analyses/paper_ranking/predictions_2024-12-11_to_2025-01-10.tsv necessary here? I imagine given the change to a single predictions.tsv we would want to end up with just that one file (and get rid of the date-specific ones) after this PR is merged but I might be missing something.

[nagutm]

@nagutm before we wrap this up: is adding the file exports/analyses/paper_ranking/predictions_2024-12-11_to_2025-01-10.tsv necessary here? I imagine given the change to a single predictions.tsv we would want to end up with just that one file (and get rid of the date-specific ones) after this PR is merged but I might be missing something.

The date specific prediction file was added before the suggestion to use just one predictions file. It can be safely removed.

[bgyori]

Alright, this looks good. The code coverage warning is an artifact of how coverage rules are applied whereby for #1358 coverage wasn't run whereas here it was - choosing to ignore this.