zenodo
connect to GitLab just as to GitHub
Dear Zenodo team,
the integration described on https://guides.github.com/activities/citable-code/ is built in a generalisable way on your end, correct? I just wanted to notify you of a discussion about Zenodo integration over at GitLab.
Cheers :-)
PS: I searched through invenio attic & contrib issues but since nothing about GitLab showed up, I hope posting this here is OK.
Hey @katrinleinweber , thanks for putting this forward. Such integration will require integration on our side, i.e. something akin to https://github.com/inveniosoftware/invenio-github
Seems like the main difficultly here would be support for custom GitLab installations. For similar reasons we're currently not supporting enterprise GitHub, which is similar to custom a GitLab instance.
May I ask why changes from your end are necessary? Can't GitLab deposit tarballs on release using your API?
Hey @remram44 You mean something like a GitLab module talking to our REST API? In fact yes, it's possible.
May I ask why changes from your end are necessary?
The changes on our end would be writing something like invenio-github module for gitlab (i.e. connecting GitLab-Zenodo accounts, registering webhooks, payload handling etc.). For example, our GitHub integration is a GitHub third party app, which requests write access to GitHub user's public repositories. User first needs to connect his GitHub account on Zenodo, so it's clear who is the "owner" of the Zenodo records is once the repo is released. So when the user enables archiving on one of his repositories (flips the switch), we register a webhook on the repo, and handle the payload when it arrives to us. At this point we can link the github user with the zenodo user.
Can't GitLab deposit tarballs on release using your API?
So now if you want to reverse it and have GitLab write to us, I can see that one could have a custom GitLab module pushing a tarball with metadata of a given repository to Zenodo, but it's not clear for which Zenodo user. I guess the easiest way would be to configure said module with the Zenodo user's API key, which would work.
one could have a custom GitLab module pushing a tarball with metadata of a given repository to Zenodo, but it's not clear for which Zenodo user. I guess the easiest way would be to configure said module with the Zenodo user's API key, which would work.
This is what I had in mind! I didn't know there Zenodo API allowed anonymous deposits anyway. Does Zenodo have something like OAuth? That might be more friendly than pasting an API key.
Thanks for taking the time to explain, @krzysztof :-)
[…] configure said module with the Zenodo user's API key, which would work.
In that case, would the module need it's own user management or refer to the GitLab instance's secrets management (EE-only?), because there would be several users on one instance, wanting their repos to hooked-up to several Zenodo accounts.
Or maybe (just speculating!) to a shared, institutional Zenodo account? But maybe this case can be ignored initially.
I didn't know there Zenodo API allowed anonymous deposits anyway
@remram44 It doesn't, you need API key. Zenodo does not have OAuth.
In that case, would the module need it's own user management or refer to the GitLab instance's secrets management (EE-only?), because there would be several users on one instance, wanting their repos to hooked-up to several Zenodo accounts.
@katrinleinweber At the moment it's not possible to have multiple owners for given records, and we wouldn't want for each repo user to have their own copy of the repository either - this would mean multiple DOIs for the same content which is bad. For that reason, given GH repo can be archived by only one user.
Several users do use something like an "institutional" account, mainly journals, but then the "burden" of record curation lies on the librarian/owner of the account, so that would technically work, but in the long term we wouldn't want this to become a mainstream solution to this problem. Instead in the future we might extend the communities feature to resemble something like a "team", and probably have some form of multiple-owners (or at least multiple curators) per record.
If the GitLab plugin takes a Zenodo API token as configuration, this seems very usable. Would also work on private installations of GitLab. It would be up to the team to decide which Zenodo account the records are created under.
Zenodo does not have OAuth.
Actually it seems to support OAuth 2.0: http://developers.zenodo.org/#authentication So entering a token by hand might not even be required.
~~As an intermittend summary, could we say that a GitLab-CI that pushes to a Zenodo-connected GitHub-repo would be a currently working alternative that gets a DOI assigned to codebase that is developed in a GitLab?~~
Not relevant anymore; Feel free to hide.
web hooks, like when a new tag is created […] seem to be the equivalent APIs used by the Zenodo integration with GitHub. […] best way would be a Project Integration configured on the GitLab side that pushes an archive of every tag when it is created.
@remram44 The above screenshot is a mock-up, right? How did you create it?
Specifically for the Zenodo module in self-hosted GitLabs, @schlauch & me posted https://gitlab.com/gitlab-org/gitlab/issues/25587.
In response to that, an experimental Invenio module was shared: https://gitlab.hzdr.de/rodare/invenio-gitlab by @tobiashuste.
A big thumbsup from me! Would simplify the pipeline of the next generation of https://zenodo.org/record/3497066!
Are there any updates on GitLab integration for Zenodo? I literally have something from GitLab that I have to publish to Zenodo right now. Even if integration is not fully supported yet, if anyone has published from GitLab to Zenodo before, I'd love to hear how you did it.
Thanks everyone.
https://pypi.org/project/gitlab2zenodo/ can be used for this, e.g. together with https://github.com/citation-file-format/cff-converter-python . I wrote a small, incomplete blog post about it here: https://www.florian-goth.de/node/18
