We currently publish to Zenodo by creating a release from the main branch and relying on the default GitHub-Zenodo integration. This has downsides:
We have to make sure that .zenodo.json is current before creating the GitHub release.
All files on the main branch are published to Zenodo.
All files published to Zenodo must exist on the main branch.
I can think of several solutions:
Maintain a custom release branch from which we create releases (e.g. https://stackoverflow.com/a/64446749/6225838). Although this sounds simple to setup, it isn't clear how to maintain this branch over time. For example, how do we run a build script (e.g. to update .zenodo.json) if that build script is only available on the main branch? And we remain forced to publish .zenodo.json to Zenodo.
Publish to Zenodo manually. Although we have full control, it would be tedious and error-prone to transcribe all of the metadata.
Publish to Zenodo automatically using their API (https://developers.zenodo.org). Although more work to setup, this would allow us to circumvent the GitHub-Zenodo integration entirely by using a custom build script triggered either manually from a local machine (perhaps to test the outcome using the Zenodo sandbox) and/or automatically with Github Actions on each GitHub release. This seems to me like the best long-term solution.
We currently publish to Zenodo by creating a release from the
mainbranch and relying on the default GitHub-Zenodo integration. This has downsides:.zenodo.jsonis current before creating the GitHub release.mainbranch are published to Zenodo.mainbranch.I can think of several solutions:
releasebranch from which we create releases (e.g. https://stackoverflow.com/a/64446749/6225838). Although this sounds simple to setup, it isn't clear how to maintain this branch over time. For example, how do we run a build script (e.g. to update.zenodo.json) if that build script is only available on themainbranch? And we remain forced to publish.zenodo.jsonto Zenodo.