对Travis和其他CI服务进行浅层克隆的缺点是什么?

Chi*_*hin 12 git continuous-integration travis-ci shallow-clone appveyor

大多数CI服务提供了一种浅层克隆存储库的方法.例如,在特拉维斯:

git:
  depth: 1
Run Code Online (Sandbox Code Playgroud)

或者在AppVeyor上:

clone_depth: 1
or
shallow_clone: true
Run Code Online (Sandbox Code Playgroud)

这有明显的速度优势,因为您不必克隆整个存储库.

CI服务的浅层克隆是否有任何缺点?是否存在浅层克隆会导致CI构建失败的情况?否则,为什么不浅层克隆这些CI服务的默认设置?

AlB*_*lue 9

它通常不会发生的原因有两个.

首先,浅层克隆的哈希值将与您在存储库中可能具有的任何版本不同.因此,无法跟踪您对任何特定结果所做的构建.

其次,如果没有详细信息,大多数Git服务器都能够发送优化的'everything.pack'.否则,服务器必须提供一个自定义提交包,其中只包含您要发送给您的浅拷贝.因此,虽然可能有更多数据通过线路传输,但实际上可能会导致服务器上的更多工作.

最后,相当多的CI构建将执行某种标记操作并将其上载到存储库,并且您实际上无法标记浅克隆(请参阅第1点).

  • 在AppVeyor和TravisCI上,相同的哈希值用于任何类型的克隆或压缩下载.它们没有与构建库匹配的问题.或者你在谈论一种不同的哈希?只要你没有在CI系统上进行任何git操作就不应该有问题. (3认同)

Far*_*way 7

默认行为和选项

Travis CI 上,默认行为是使用 50 的克隆深度。
TravisCI 文档, git-clone-depth

git:
  depth: 3
# Or remove the --depth flag entirely with:
git:
  depth: false
Run Code Online (Sandbox Code Playgroud)

AppVeyor 上,默认是克隆整个存储库。
AppVeyor 提供设置克隆深度和替代shallow_clone: true选项,其中使用 GitHub 或 Bitbucket API 将提交下载为 zip 存档。(AppVeyor 文档。)

参考 appveyor.yml 中的描述:

# fetch repository as zip archive
shallow_clone: true                 # default is "false"

# set clone depth
clone_depth: 5                      # clone entire repository history if not defined
Run Code Online (Sandbox Code Playgroud)

不要在您的 CI 项目中使用 depth=1!

(clone_)depth: 1当在 CI 平台开始克隆预期提交之前将新提交推送到分支时,使用经常会导致 git 错误。在 AppVeyor 和 TravisCI 上都可以正常推送操作到 GitHub 上的存储库。

AppVeyor 上结账失败的示例输出:

Build started
git clone -q --depth=1 --branch=<branch_name> https://github.com/<user>/<repo_name>.git C:\projects\<repo_name>
git checkout -qf 53f3f9d4d29985cc6e56764c07928a25d94477ed
fatal: reference is not a tree: 53f3f9d4d29985cc6e56764c07928a25d94477ed
Command exited with code 128
Run Code Online (Sandbox Code Playgroud)

请注意,没有拉出特定的提交!

使用 AppVeyors 替代方案shallow_clone: true

Build started
Fetching repository commit (6ad0f01)...OK
Total: 781.1 KB in 76 files
Run Code Online (Sandbox Code Playgroud)

我没有看到使用该shallow_clone: true设置的项目有任何问题。

在旧提交上重新启动构建

使用有限深度时的第二个结果是,当超出此范围时,在旧提交上重新启动 CI 构建将失败。

建议

在 AppVeyor 上,shallow_clone: true如果存储库在 GitHub 或 Bitbucket 上可用,我会建议使用。除非你想对代码进行 git 操作,否则这似乎是最好的选择。

在 TravisCI 上不设置深度(并使用默认深度 50)似乎是合理的。如果您不想根据存储库上的流量触发历史构建或优化,您可以使用不同的值。

克隆依赖

外部依赖通常由分支或标签引用。当获取分支的尖端或标记被克隆时,使用 git flag 应该没有问题--depth=1


Chi*_*hin 5

添加到AlBlue的答案中:

另一个问题是克隆深度设置也用于git子模块。

在使用git子模块的项目中,Travis等将从母版开始克隆子模块存储库,然后签出特定的修订版。

如果我们在子模块中指向的提交不在当前主控的n次提交中(其中n是深度设置),那么它将无法检出。