如果我在 github 上创建发布时自动创建的存档包含我的 git repo 可能包含的任何 git 子模块,那就太好了。 我相信,例如这个包https://github.com/Kentzo/git-archive-all使这变得非常简单。
感谢您的建议!
需要考虑的一件事是我们是否有权将所有子模块代码与用户代码一起包含在存档中。
关于权利:对于所有子模块也在 zenodo 上的存储库,这不是问题,因此至少可以在受限情况下启用。 包含子模块对于代码的实际可重现性当然是必不可少的。
作为解决方法,可以使用 CI 脚本生成包含相关子模块内容作为资产的版本。 但是,由于 #1235 ,这目前也不起作用。
例如,这是我用于 Travis CI 的设置:
before_deploy:
- zip -r inamo-${TRAVIS_TAG}.zip . -x out\* plots\* .git\* regRefData/.git\*
deploy:
provider: releases
edge: true
api_key:
secure: "***"
file: inamo-${TRAVIS_TAG}.zip
release_notes_file: README.md
tag_name: ${TRAVIS_TAG}
name: InaMo ${TRAVIS_TAG}
on:
tags: true
draft: true
另一方面,这样的事情可以解决许可问题吗? 或者这是否意味着后端需要太多的配置工作?
我认为不包括子模块并且不警告用户重要文件可能丢失的事实可能是可重复性的主要问题。 例如,我只注意到我上传的一个子模块内容丢失了,因为一个特别勤奋的审阅者实际上下载了 Zenodo 版本并尝试运行我文章中描述的模拟。
Zenodo 知道或尝试验证用户打算包含哪些子模块或有权使用哪些子模块是不合理的,因此只需让它成为.zenodo.json
的配置项
最有用的评论
另一方面,这样的事情可以解决许可问题吗? 或者这是否意味着后端需要太多的配置工作?
我认为不包括子模块并且不警告用户重要文件可能丢失的事实可能是可重复性的主要问题。 例如,我只注意到我上传的一个子模块内容丢失了,因为一个特别勤奋的审阅者实际上下载了 Zenodo 版本并尝试运行我文章中描述的模拟。