Finish automation & add a GitHub Action

[joeflack4]

Tasks

• [x] 1. Finish automation: Download of the text files needs to be doable in order to finish the automation, and I think that's it.
• [ ] 2.1. GitHub action: runs the command to install dependencies and run to create the generated artefact: pip install -r requirements.txt and python -m omim2obo
• [ ] 2.2 GitHub action: Use GitHub API to make a new release. For the release tag and title, you put date in the form YYYY-MM-DD.

[joeflack4]

Currently, running the action will overwrite the existing latest release.

[matentzn]

We def. need the versioned releases asap - there should not be a latest release without a corresponding versioned release.

Indeed, latest is managed by github: creating a versioned release is all you need to do!

[joeflack4]

I think I did this for ease of downstream slurping. Wasn't sure if the GitHub REST API allowed you to see which one was the latest, but I know it can check for explicit tags. So the idea was that it would check the releases, find the one with the tag latest, and use that. But maybe it does allow you access to see the latest release, regardless of what the tag is. Something to check on when we automate the slurping as well.

In the past, I've made a versioned release in addition to the one tagged latest. I didn't do that yet today but I'll do that now.

I do agree it is very good if the releases are versioned automatically. However, I don't know what a good solution to this problem is: If we're using semver, there isn't really a good way for a script to know whether or not a release is a (a) major update, (b) minor update, (c) patch update.

Possible solutions?

• Move from semver to something else
• Patch: Make every automatic release be a patch release. A human can manually change afterwards if that isn't accurate.
• Minor: Make every automatic release be a minor release. A human can manually change afterwards if that isn't accurate.

[matentzn]

Github has now a latest without you having to do any tagging!

Instead of semver, we can use date based versioning like in OBO: 2022-11-30

[joeflack4]

I'm fine with these changes. Will address when I get back to working on this issue.

[joeflack4]

Updated issue to reflect new decision. Pasting old semver approach below, just for historical purposes.

~2.2 Use GitHub API to make a new release. For the release tag/label, you can put pre_release. 2.3. The difficult part. The previous release will still be labeled latest_release. That label needs to be removed and replaced with a new semver version. It's impossible, without knowing the change details, whether the minor version number 1.x.0 or the patch version number 1.0.x should be incremented, but for now let's do the patch version. So if the latest version before was called 1.0.3, the next one should be 1.0.4. The reason it's important to have the most recent release called "latest_release" is because other scripts will be looking for that specific tag in order to download it later. 2.3.1. The previous latest_release should be changed to a semver (x.x.x) style version as mentioned in 2.3. 2.3.2. Now change the tag for the new release called pre_release in step 2.2 to latest_release.~