search

rseng / zenodo-release

Automated releases to zenodo without granting admin access to webhooks
MIT License
10 stars 4 forks source link

add the ability to make a new version on an existing doi #2

Closed johrstrom closed 2 years ago

johrstrom commented 2 years ago

Fixes #1.

I ran out of time today to update the README and test that creating brand new DOIs still work. Indeed - because I don't now much about GH action internals, I don't know if the action.yml is correct (for example doi being optional).

In any case - I don't work after hours or on the weekend so I'll pick this back up on Monday. I'd be happy to refactor it a bit so maybe all that stuff is in a separate function and so on (and/or change anything, I'm not super strong in python)? Either way - I'll see comments then.

This is what I'd been testing with

#!/bin/bash

VERSION='2.0.0'
JSON="/home/jeff/ondemand/misc/test-actions/.zenodo.json"

python3 scripts/deploy.py upload --zenodo-json $JSON --version $VERSION "$VERSION.zip" --doi '10.5281/zenodo.6323748'
vsoch commented 2 years ago

Sounds good! With your permission I'd be happy to work on the PR, probably this evening or in the weekend. Otherwise I will leave to you for Monday! Have a good weekend!

johrstrom commented 2 years ago

Sorry, didn't see this message until now.

But you could have merged or edited it, would have been perfectly OK with me.

In any case - I know I've got the README to update and maybe add a comment. I'll have both shortly.

vsoch commented 2 years ago

Sounds good! And no worries I did a ton this weekend and probably couldn't have fit it in (or if I did I wouldn't have been able to do the other stuffs!) Thanks @johrstrom

johrstrom commented 2 years ago

Cool. Updates made. Let me know if there's anything you'd like changed.

vsoch commented 2 years ago

@johrstrom are we able to test this? Here is the record I created on release - is it going to work to change the trigger to PR to test, or do we need to fully merge to test?

Thinking about this - I think my preference would be to add a staging variable that changes the URL to use the staging Zenodo url, and then we can run that version on pull request to test.

johrstrom commented 2 years ago

do we need to fully merge to test?

Thank you for thinking smarter than me. I'm testing on and it didn't work out of the box. So I'll need a second to fix and confirm it. https://github.com/johrstrom/test-actions.

I think my preference would be to add a staging variable

Do you want that as a part of this PR?

vsoch commented 2 years ago

@johrstrom if we need to test this before merging, I don't think we have a choice! If you don't want to / are unable to do it I can take over and try in an evening - it should be fairly trivial to add a boolean staging to the action.yaml, have that feed into entrypoint.sh (if it's defined add a --staging flag, and given that flag, flip the URL to use the staging site.

johrstrom commented 2 years ago

Well, should have tested this a bit more before this stage. This seems to work for the next version, but not any subsequent versions.

I'm going to cancel this PR altogether. I got this to work, but apparently we need a new DOI every time. Here's a snippet of what we need to do/is happening.

create a release manually - doi/A
use doi/A in this action -> creates doi/B (the next version of doi/A)

use doi/A in this action  -> fails to create doi/C because it actually requires doi/B, the latest version.

So somehow we need to be given information that'll work for subsequent releases (or use the DOI differently somehow?).

Since I foolishly didn't branch this, I'm going to reset my main be in sync with this repo and put all this work on a upload-new-version branch.

vsoch commented 2 years ago

Sounds good @johrstrom ! And it's totally okay if you push 100 commits to test things out, it's hard to get things right the first time, and I'm okay with that :)

I do know for a fact that we cannot use a DOI that has been created in the interface - you get an error that it's "managed locally" or something like that (I put this note in the README I believe). So I think we'd need to use a DOI that was generated programatically, if it works at all.

If it ultimately doesn't, let's write up a summary and ping some folks from Zenodo, because this kind of thing really should work.

johrstrom commented 2 years ago

Cool. I'll keep plugging along, I just didn't want to bother you with all the updates I'd push.

I'll re-open something when/if I get this to work.

vsoch commented 2 years ago

Sounds good! And you aren't bugging me at all, I love working on these little projects, and it's more fun to have a friend :) I'm definitely alright with managing my GitHub notifications - and let me know if you want to chat about anything or want help at any point.

johrstrom commented 2 years ago

Awesome! Well at this point I need to figure the API a little more. Clearly they're keeping a lot of state on their side and have rules around what you can edit and so on. I need some way to find this artifact among many, where the id has clearly changed when versions increment - i.e., you can only call newversion on the latest version, whatever that may be. I guess the trouble is just finding out what doi is the latest version of the thing you want to edit is the trick.

vsoch commented 2 years ago

Success!!! So here is the upload from the action https://doi.org/10.5281/zenodo.6326822 merged in #6 - now you can provide that "all versions" API and it looks to draft and publish a new one, still with a DOI but associated with the old one! I also added an ability to provide pattern matches to the archive (but not a list yet).

Let me know what you'd like to try / work on next! This latest one should be release 0.0.16 (what you can use for the GitHub ref if not main branch).