Update Stable Major Releases of PDS software with DOIs

[jordanpadams]

Per the JPL-PDS Open Source Policy:

Each major release of the software must have a persistent identifier such as a Digital Object Identifier (DOI). 

Open Questions

• The policy says "persistent identifiers". DOIs are the default for this outside of the PDS. Is that the route we want to take?
• Apparently this is pretty easily integrated with Github, but, surprise, I don't think it is easily automated. Can we automate? Or is it just a procedural update to the wiki?

[jordanpadams]

@nutjob4life i think this one is next before we move onto continuous deployment

[nutjob4life]

Oh yeah, I heard rumors about DOIs on software releases!

[jordanpadams]

@nutjob4life btw, here is the info from Github on this as a starter: https://guides.github.com/activities/citable-code/

[nutjob4life]

This actually might be pretty trivial. I tried a quick integration with Zenodo and was able to automatically get DOIs assigned to this sandbox repository (scroll down to see the DOI badge):

https://github.com/nasa-pds-engineering-node/epitome

If that satisfies the requirement, I can go ahead and enable this on the non-sandbox repositories. Sound okay @jordanpadams @tloubrieu-jpl ?

[jordanpadams]

@nutjob4life awesome!

Can we make it so it only assigns a new DOI for major version change (e.g. 1.x, 2.x, etc.)? If so, this would be perfect!

[nutjob4life]

@jordanpadams: Currently, the Zenodo integration assigns a DOI to the repository (10.5281/zenodo.5643445 = PDS Epitome) and then subsequent DOIs to every single release from that repository (10.5281/zenodo.5643446 = PDS Epitome stable release 1.8.6, 10.5281/zenodo.5643489 = PDS Epitome unstable release 1.8.7-dev).

Personally I think it's okay since the DOIs are essentially free ☺️ and there's always the repo-level DOI. Would the repo-level DOI work?

Researching further, we might be able to do something with their API in order to do vMAJOR+1.MINOR.MICRO DOI assignments. The API looks a bit more involved than the 1-line webhook which has the benefit of being … well … one line! 😅

[jordanpadams]

@nutjob4life I'm ok with repo level and every release... I think that suffices for me.

thoughts @tloubrieu-jpl ?

[tloubrieu-jpl]

I think zenodo is the standard solution for software DOIs

[tloubrieu-jpl]

@jordanpadams @tloubrieu-jpl will share the prefix used for the dataset's DOI. This requires some more thought on how to combine/filter in between datasets and software DOIs.

[nutjob4life]

• JPL PDS EN DOI prefix = 10.17189
• Or try a test DOI from dataCite
• Or stick with Zenodo … it is the standard solution for software DOIs

[tloubrieu-jpl]

There was an issue with the github/zenodo integration which should be solved now.

We will stick with using the zenodo assigned DOI prefix.

[tloubrieu-jpl]

The production PDS organization in zenodo can be found here: https://zenodo.org/communities/nasa-pds/ The test one is: https://zenodo.org/communities/nasa-pds-test/

[tloubrieu-jpl]

There is a bug number of requests done to the github api which reaches the limit authorized per hour.

[jordanpadams]

@tloubrieu-jpl I'm assuming this is unrelated to the actual DOI creation, but rather the requirements / changelog generation?

[nutjob4life]

@jordanpadams, this seems to be the case. When I made a release "by hand", my API use count went up by 3 after Zenodo assigned the DOI and archived the repository. But after experimenting with Roundup releases, I saw thousands of API requests (3800 out of 5000 in one hour).

I'm watching this to ensure it's not the DOI assignment that's responsible for this massive API usage.

[tloubrieu-jpl]

The action to close this ticket is to deploy a webhook on all the repository for which we want to create DOIs.

We should start from the list used to retrofit the repositories to match the templates.

[jordanpadams]

• [ ] https://github.com/NASA-PDS/transform
• [ ] https://github.com/NASA-PDS/pds4-jparser
• [ ] https://github.com/NASA-PDS/pds-api-javalib
• [ ] https://github.com/NASA-PDS/registry-api-service
• [ ] https://github.com/NASA-PDS/pds-api-client
• [ ] https://github.com/NASA-PDS/pds-api
• [ ] https://github.com/NASA-PDS/nasa-pds.github.io
• [ ] https://github.com/NASA-PDS/pds4-information-model
• [ ] https://github.com/NASA-PDS/validate
• [ ] https://github.com/NASA-PDS/pds-deep-archive
• [ ] https://github.com/NASA-PDS/pdsen-corral
• [ ] https://github.com/NASA-PDS/pds-github-util
• [ ] https://github.com/NASA-PDS/pds-doi-service
• [ ] https://github.com/NASA-PDS/harvest
• [ ] https://github.com/NASA-PDS/pds-registry-app
• [ ] https://github.com/NASA-PDS/pds-api-notebook
• [ ] https://github.com/NASA-PDS/pdsen-operations
• [ ] https://github.com/NASA-PDS/api-search-query-lexer
• [ ] https://github.com/NASA-PDS/pds-registry-mgr-elastic - TBD - possible combine with Harvest
• [ ] https://github.com/NASA-PDS/pds-registry-common - TBD - possible combine with Harvest
• [ ] https://github.com/NASA-PDS/supplementer - TBD - possible combine with Harvest
• [ ] https://github.com/NASA-PDS/pdsen-maven-parent
• [ ] https://github.com/NASA-PDS/pds-view
• [ ] https://github.com/NASA-PDS/mi-label
• [ ] https://github.com/NASA-PDS/pds-template-repo-java (if webhooks get inherited when you use a template. if not, let's just update the wiki docs for what to do when you create a new repo)
• [ ] https://github.com/NASA-PDS/pds-template-repo-python (same as the java template)

[jordanpadams]

@nutjob4life ☝️

[nutjob4life]

@jordanpadams you sure about including https://github.com/NASA-PDS/pdsen-corral? There's not any software that I can see in that repository.

Same goes for nasa-pds.github.io, pdsen-operations

[jordanpadams]

@nutjob4life you can skip it. it runs github actions and pushes to our nasa-pds.github.io website, but it is really just at facilitator more than it is a software repo

[jordanpadams]

@nutjob4life also, do we need to add the patch the README? Or does this happen auto-magically?

[nutjob4life]

@jordanpadams READMEs?

Oh you mean for the DOI badge? We can't add those until at least one release [1] has been made, since that'll assign a DOI, and then that gives us a badge image URL.

[1] A pre-release counts.

[jordanpadams]

@nutjob4life copy. so we may need another ticket for rolling out the badges depending upon timing with the close of the sprint

[jordanpadams]

Stable releases updated and DOIs ready for tagging one releases are tagged.