softwarepub / ci-templates

Continuous integration templates for automatic software publication with HERMES
https://docs.software-metadata.pub
1 stars 1 forks source link

how to get rid of --initial and take versioning into account #10

Closed Chilipp closed 7 months ago

Chilipp commented 7 months ago

moin @poikilotherm @sdruskat @led02 and @daniel-mohr !

thanks for your great work on this! Unfortunately I could not take part in the workshop at the deRSE24, as I had my own workshop at exactly the same time. I created a bunch of software-templates that I use to maintain python packages and other stuff (https://events.hifis.net/event/994/contributions/7994/) and I would very much like to integrate the hermes workflow as an option here. And so far, it works quite well

https://codebase.helmholtz.cloud/hcdc/software-templates/python-package-template/-/merge_requests/31

and I created a small demo repository based on this template at https://codebase.helmholtz.cloud/hcdc/software-templates/demos/hermes-ci-demo/ that publishes stuff to sandbox.zenodo.org

as I am very new to the hermes workflow, please forgive me, when there are shortcomings in my understanding how all of this works.

I was able to publish the demo-package to sandbox.zenodo.org from the hermes workflow (see https://sandbox.zenodo.org/records/34392) for instance (done in this pipeline), but with the --initial option, I have now two different repositories in zenodo:

I would have expected, that hermes uses the same repository on zenodo and just create a new version here. but apparently, it creates an entire new repository and does not use zenodos versioning approach. I presume that this is because of the --initial option in the hermes deposit command, but when I try to remove it, hermes complains that this is needed (see this pipeline)

as a second point (and if you like, I can open a new issue for this), is there a possibility such that we can specify the versioning when the repository is created? My package is using versioneer here and zenodos rest API also supports using a custom version. currently, hermes just publishes the packages a v1 on zenodo

led02 commented 7 months ago

Hi @Chilipp, first of all thank you for using Hermes and giving such valuable feedback.

For the fist part of your question: To deposit a new version for a record, you need to somehow reference any old version. This can be done by adding a DOI to the CFF or by setting the deposit.invenio_rdm.record_id in the hermes.toml. Usually, this should be done automatically by a post processing step, which is currently due to ongoing refactoring not working.

This brings me to you second point: We harvest the version from the CFF or Codemeta file. This can of course be extended by you harvest plugin. If no version is given, Zenodo makes v1 of it. However, the version needs to be changed to allow following depositions.

I’m out of office until Thursday, so excuse my briefness and missing fixes, but be sure we’ll look into this, soon!

Chilipp commented 7 months ago

awesome! I can work with this, thank you :smiley:

daniel-mohr commented 7 months ago

@Chilipp In your hermes-ci-demo/ you have many owners. How do you handle the zenodo token? (cf. https://github.com/hermes-hmc/hermes/issues/203)

If you provide the zenodo token as CI variable HERMES_PUSH_TOKEN you shared it at least with every owner and maintainer. As it is used in a temporary branch (created and deleted by hermes) I expect further the CI variable is not protected and could be used as developer in every branch with code defined by a developer.

Otherwise I would be very interested how you overcome this problem. Any hints?

Chilipp commented 7 months ago

moin @daniel-mohr! yes, this is indeed a problem. and one cannot protect this variable because the branches that hermes create are not protected ones (otherwise hermes would not be able to delete the branches for curation).

so my only solution (which would at least reduce the risk for other projects) is to create a deposit-specific account at https://zenodo.org and use the token from this user. If a developer in a repo then decides to make evil things, he or she can at least only do it for the specific project that he or she has access to.

do you have any other idea?

daniel-mohr commented 7 months ago

In my comment https://github.com/hermes-hmc/hermes/issues/203#issuecomment-1735115366 I tried to describe some possibilities -- but these are not implemented!

In https://github.com/hermes-hmc/hermes/issues/203#issuecomment-1824901951 I mentioned another workflow deploy_deploy2zenodo_to_zenodo. But this is not hermes! And it does not do the harvesting step -- maybe it could be joined with hermes somehow.

led02 commented 7 months ago

Yes, Hermes could be used in the workflow of @daniel-mohr to do the conversion (replace cffconvert) and deposition (replace ja, curl).Von meinem iPhone gesendetAm 13.03.2024 um 10:09 schrieb daniel-mohr @.***>: In my comment hermes-hmc/hermes#203 (comment) I tried to describe some possibilities -- but these are not implemented! In hermes-hmc/hermes#203 (comment) I mentioned another workflow deploy_deploy2zenodo_to_zenodo. But this is not hermes! And it does not do the harvesting step -- maybe it could be joined with hermes somehow.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were assigned.Message ID: @.***>