Badges doi

[kpsherva]

• closes https://github.com/zenodo/rdm-project/issues/354

[slint]

The pid in this case, is it the DOI or the RECID? That depends on what the GitHubRelease.pid class has configured in invenio-rdm. And I also see that the class above is not "dynamically" picked up using the GITHUB_RELEASE_CLASS config.

[slint]

I think the solution is to implement a badge_pid property on the GitHubRelease class, and in RDM Records resolve and return the DOI PersistentIdentifier.

[alejandromumo]

We already have this (badge_title and badge_value) and both are meant to work with DOI. Unfortunately, it was only enabled for the new badge endpoint, not the older ones ...

I think we only need to fix this in invenio-github

[alejandromumo]

This is not used anywhere ... in fact latest_published is not even a view arg

[alejandromumo]

The issue here was that all of these were copy / pasted from legacy and were not properly adapted to the new architecture. E.g.:

• Badge title: will be DOI if datacite is enabled (like on Zenodo)
• Badge value: will take the DOI identifier from record pids if Datacite is enabled
• Record url: will be either the record DOI URL if the record has one, otherwise it's HTML url

[alejandromumo]

If we use these, which are already in place, we can remove this legacy logic based on pid and some hardcoded stuff (e.g. doi URL)

[alejandromumo]

The release object might not exist since latest_release returns an object from query.first(). This could lead to problems further down the road.

I modified the calls to repo_last_published_release to either get the release instance or throw an error (usually in the presentation layer throws a 404)