Obtain publication version from tag and update e.g. CITATION.cff via CI ?

[FObersteiner]

I noted that hermes obtains the version for the publication from the CITATION.cff file, if I configure it to harvest that.

There seem to be two problems with that,

1. If I have anything specified in the identifiers section of the CITATIONS.cff, the deposit job just fails. This is problematic since I want to use this section to list previous releases as well as the current release, together with their DOIs. I might make this a separate issue since it seems like a bug to me.
2. If I want to use git's tagging to trigger a release, the tag must determine the release version - otherwise I'd still have to update the CITATION.cff file manually before, which kind of defeats the purpose of the automation effort

Related: #322 - I got that working by some tweaks of the CI script, however as described above, I think this requires automated update of the harvested resources.

Did I miss anything? Or is my plan just outside of the scope of hermes?

(potentially related: #63, #131)

[led02]

Thanks for your comment.

In fact, the first issue seems to be a bug or something related to the CFF harvesting plugin. If the CFF file is valid, it should not fail.

The second issue is a mix of configuration and not implemented yet.

The git harvesting plugin does currently not collect the version number and needs to be extended to collect the tag as version number.

To write the version back to your CFF file could be done in the post processing step but this would be too late for deposition. Hence, you might want to update your CFF file during the build process before calling hermes. @poikilotherm Could be an idea for a template feature as this might be a quite common use case.

I think this is also a question that should be discussed in an ADR as it touches major design decisions: Currently, hermes is designed to publish ready built artifacts. However, it might be useful to add a prepare step that can update metadata before publication similar to post processing.

[FObersteiner]

@led02 thanks for the response! Regarding 1) I'll look into that and make a separate issue as soon as I find the time again to fool around with hermes ;-)

Concerning my main point, my guess would be that a git tagging-based release model isn't uncommon at least. On the other hand side, triggering a release on any push to the main branch seems kind of impractical to me. Note that I gave hermes a first try today, as a user, and am not too deep into it (yet). Not sure if it's possible to obtain a DOI prior to publishing via zenodo's API (but would seem reasonable to me). If so, a prepare step could obtain that, update cff file etc. so that this is all consistent in the archive that is then published. It might be kind of a chicken-egg-problem regarding how this gets into the main branch - if it's part of the post-merge request, the tag would actually be off, no?

[led02]

I have to admit that the current "collection" of templates is still very sparse and centered around git-flow branching pattern. Providing a sane on-tag template is certainly high priority.