Zenodo: 像连接 GitHub 一样连接到 GitLab

创建于 2018-01-11  ·  20评论  ·  资料来源: zenodo/zenodo

亲爱的 Zenodo 团队,

https://guides.github.com/activities/citable-code/上描述的集成是在您的终端以通用方式构建的,对吗? 我只是想通知你在 GitLab 上关于 Zenodo 集成的讨论

干杯:-)

Feature request Needs investigation i - Asclepias Accepted

最有用的评论

专门针对自托管 GitLabs 中的 Zenodo 模块, @schlouch和我发布了https://gitlab.com/gitlab-org/gitlab/issues/25587。

对此,@tobiashuste 分享了一个实验性的 Invenio 模块: https ://gitlab.hzdr.de/rodare/invenio-gitlab。

所有20条评论

PS:我搜索了invenio阁楼contrib问题,但由于没有任何关于 GitLab 的信息出现,我希望在这里发布这个是可以的。

@katrinleinweber ,感谢您提出这一点。 这种集成需要我们这边的集成,即类似于https://github.com/inveniosoftware/invenio-github 的东西

似乎这里的主要困难是支持自定义 GitLab 安装。 出于类似的原因,我们目前不支持企业 GitHub,这类似于自定义 GitLab 实例。

我可以问为什么需要从您的一端进行更改吗? GitLab 不能使用您的 API 在发布时存放 tarball 吗?

@remram44你的意思是类似于 GitLab 模块与我们的 REST API 对话? 事实上是的,这是可能的。

我可以问为什么需要从您的一端进行更改吗?

我们最终的变化是为 gitlab 编写类似 invenio-github 模块的内容(即连接 GitLab-Zenodo 帐户、注册 webhooks、有效负载处理等)。 例如,我们的 GitHub 集成是一个 GitHub 第三方应用程序,它请求对 GitHub 用户的公共存储库进行写访问。 用户首先需要在 Zenodo 上连接他的 GitHub 帐户,所以一旦 repo 发布,谁是 Zenodo 记录的“所有者”就很清楚了。 因此,当用户在他的存储库之一上启用存档(翻转开关)时,我们在存储库上注册一个 webhook,并在它到达时处理负载。 此时我们可以将 github 用户与 zenodo 用户关联起来。

GitLab 不能使用您的 API 在发布时存放 tarball 吗?

所以现在如果你想反转它并让 GitLab 写信给我们,我可以看到一个自定义的 GitLab 模块可以将带有给定存储库元数据的 tarball 推送到 Zenodo,但不清楚哪个 Zenodo 用户。 我想最简单的方法是使用 Zenodo 用户的 API 密钥配置所述模块,这将起作用。

可以有一个自定义的 GitLab 模块,将带有给定存储库元数据的 tarball 推送到 Zenodo,但不清楚哪个 Zenodo 用户。 我想最简单的方法是使用 Zenodo 用户的 API 密钥配置所述模块,这将起作用。

这就是我的想法! 我不知道 Zenodo API 允许匿名存款。 Zenodo 有类似 OAuth 的东西吗? 这可能比粘贴 API 密钥更友好。

感谢您花时间解释, @krzysztof :-)

[…] 使用 Zenodo 用户的 API 密钥配置所述模块,这将起作用。

在这种情况下,模块是否需要自己的用户管理或参考 GitLab 实例的机密管理(仅限 EE? ),因为一个实例上会有多个用户,希望他们的存储库连接到多个 Zenodo 帐户。

或者(只是推测!)共享的机构 Zenodo 帐户? 但也许这种情况最初可以被忽略。

我不知道 Zenodo API 允许匿名存款

@remram44不是,您需要 API 密钥。 Zenodo 没有 OAuth。

在这种情况下,模块是否需要自己的用户管理或参考 GitLab 实例的机密管理(仅限 EE?),因为一个实例上会有多个用户,希望他们的存储库连接到多个 Zenodo 帐户。

@katrinleinweber目前,给定记录不可能有多个所有者,我们也不希望每个 repo 用户拥有自己的存储库副本 - 这意味着同一内容的多个 DOI 是不好的。 出于这个原因,给定的 GH 存储库只能由一个用户存档。

一些用户确实使用诸如“机构”帐户之类的东西,主要是期刊,但是记录管理的“负担”在于该帐户的图书管理员/所有者,因此这在技术上是可行的,但从长远来看,我们不希望这成为解决这个问题的主流方法。 相反,在未来,我们可能会将社区功能扩展为类似于“团队”之类的东西,并且每个记录可能具有某种形式的多个所有者(或至少多个策展人)。

如果 GitLab 插件采用 Zenodo API 令牌作为配置,这似乎非常有用。 也适用于 GitLab 的私人安装。 由团队决定在哪个 Zenodo 帐户下创建记录。

screen shot 2018-01-15 at 11 47 29

Zenodo 没有 OAuth。

实际上它似乎支持 OAuth 2.0: http :

作为一个间歇性的总结,我们是否可以说,推送到 Zenodo 连接的 GitHub 存储库可行的替代方案,它将 DOI 分配给在 GitLab 中开发的代码库?

不再相关; 随意隐藏。

GitLab 建议

网络钩子,比如当一个新标签被创建时 […] 似乎是 Zenodo 与 GitHub 集成使用的等效 API。 […] 最好的方法是在 GitLab 端配置一个项目集成,在创建时推送每个标签

@remram44上面的截图是一个模型,对吧? 你是如何创造的?

@katrinleinweber Firefox 检查器/开发工具 :wink:

专门针对自托管 GitLabs 中的 Zenodo 模块, @schlouch和我发布了https://gitlab.com/gitlab-org/gitlab/issues/25587。

对此,@tobiashuste 分享了一个实验性的 Invenio 模块: https ://gitlab.hzdr.de/rodare/invenio-gitlab。

这个功能很有用,我们如何投票?

继续发帖直​​到引起更多关注😉

毫无疑问,这对 Zenodo 来说将是一个有趣的功能。

是的,请 !

我也想用这样的插件!

好主意,将非常有用!

给我一个大大的赞! 将简化下一代https://zenodo.org/record/3497066的管道

此页面是否有帮助?
0 / 5 - 0 等级