search

ersilia-os / ersilia

The Ersilia Model Hub, a repository of AI/ML models for infectious and neglected disease research.
https://ersilia.io
GNU General Public License v3.0
203 stars 131 forks source link

Batch: Automatically upload Ersilia versions to Zenodo #705

Closed miquelduranfrigola closed 1 week ago

miquelduranfrigola commented 1 year ago

Ersilia is linked to the following Zenodo repository. This is necessary to have a citation file (CFF).

It would be good to have a GitHub Action that is triggered every time we do a new Ersilia release and uploads it to Zenodo.

honeyankit commented 1 year ago

every time we do a new Ersilia release and uploads it to Zenodo

@miquelduranfrigola: Which pipeline is doing Ersilia release, can you share that? Also, currently how uploading toZenodo is happening? Could you share those steps as well?

honeyankit commented 1 year ago

[not urgent]: Also, how do I change the status of the this task to inProgress ?

miquelduranfrigola commented 1 year ago

Thanks @honeyankit

I have changed the status of this task to 'In Progress'

We currently do not have a workflow to create releases. I was looking into this option: https://github.com/marketplace/actions/automatic-releases , but there are other options I believe.

In my opinion, we could take 3 approaches:

  1. Create a release in coordination with creation of a 'tag'. That is, each time we create a tag, we also create a release.
  2. Create a release when a specific pattern is matched, either in the version (semantic v{x}.{y}.{z}) or in the commit message (-m "Release blahblah")
  3. Create a release every time the changelog is modified.

I think my favourite option is (1). But what do you think?

Currently, the Ersilia Model Hub is syncronized to this Zenodo record: https://zenodo.org/record/8084902 I have just checked and Zenodo automatically updates its records every time a new release of Ersilia is created, so no need to set up a specific action for uploading to Zenodo. The only thing we need to do is to automate the createion of releases.

honeyankit commented 1 year ago

@miquelduranfrigola Thank you for all the 3 approaches. Those are great suggestions.

  1. Create a release in coordination with creation of a 'tag'. That is, each time we create a tag, we also create a release.

Do we also maintain any ersilia version in the repo. If yes then we also need to update that.

  1. Create a release when a specific pattern is matched, either in the version (semantic v{x}.{y}.{z}) or in the commit message (-m "Release blahblah")

Little optimization here, We can maintain a erslila version file in the Ersilia repo and when the PR is created, Github action is invoked with any version change in this file on PR creation task. This will lead to creation of new release and tag. This can be done automatically (I hope, might need to look deep into it).

  1. Create a release every time the changelog is modified.

I will stick to first two options, also while creating release GitHub can automatically generates changelog based on commit messages of all the PR merged in repo.

miquelduranfrigola commented 1 year ago

Thanks @honeyankit

It is great that we can edit changes in the CHANGELOG automatically. I would certainly do this.

Let's hope this helps to answer your points:

Based on what we have, perhaps the easiest will be to create a release in coordination with tag (and version) creation. I would simply name releases Ersilia v0.1.14, and add changes to the changelog and realease descripton automatically.

What do you think?

honeyankit commented 1 year ago

Thank you for all the info. I also started looking at the workflow file tag-to-version.yml. Based on my understanding and your suggestions, I will modify this workflow to create release and its change-log.

miquelduranfrigola commented 1 year ago

I think this would be the perfect solution. Thanks so much @honeyankit !

honeyankit commented 1 year ago

@miquelduranfrigola : I noticed, the tag-to-version.yml is committing directly to master. I would like to propose a alternate solution:

  1. The tag-to-version.yml creates a new branch with a unique name based on the GitHub run ID.
  2. It adds and commits changes to this new branch, then pushes the branch to the remote repository.
  3. It creates a pull request from this new branch to the master branch. You can specify reviewers for this pull request.
  4. The pull request is labeled with auto-merge and is merged to the master branch.
  5. Post that release and the changelog will be created.

With the above approach, we avoid committing to the master branch. Let me know your thoughts else I am fine to implement the previous solution.

Note: All the above actions will be still be preformed in a tag-to-version.yml workflow. The only difference you will notice is that we are now creating a branch/PR and not directly pushing the version to the master branch.

miquelduranfrigola commented 1 year ago

I think this is a much better solution than mine - as long as it is not too difficult to implement! As you know, I am slowly learning actions workflows, so I am sure my files can be improved.

If we follow your approach, can we delete the newly created branch at the end of the workflow?

honeyankit commented 1 year ago

If we follow your approach, can we delete the newly created branch at the end of the workflow?

Yes, surely we can delete the branch in the end. Also, If I remember correctly, we can set that option in repo settings where once the PR is merged the branch are deleted automatically. I do not have admin access but you should be able to look into that.

miquelduranfrigola commented 1 year ago

Perfect, thanks @honeyankit !

honeyankit commented 1 year ago

Cool Thanks, I will implement this tomorrow too late for me now. I have all the info I need. Thank you so much @miquelduranfrigola!

miquelduranfrigola commented 1 year ago

Of course, no rush at all!

GemmaTuron commented 8 months ago

Hi @honeyankit !

We'd like to complete this github action. If you are too busy at the moment no worries, just let us know and we will take over :)

DhanshreeA commented 3 months ago

New addition: We need to update the CITATION.CFF file every time we make a release to reflect the correct DOI and release version

miquelduranfrigola commented 3 months ago

Hi @DhanshreeA - as discussed, the DOI should not be updated, only the release version. Zenodo provides a stable DOI that is an umbrella for all releases.

GemmaTuron commented 1 week ago

Hi,

We need to close this, particularly in light of the FAIR-Impact project. Is this completed @DhanshreeA?

DhanshreeA commented 1 week ago

This already happens since we turned syncing on for our GitHub releases on the Zenodo account. The plan is that we maintain the umbrella DOI in both the README and the CITATION.cff file.