Jenkins Pipeline：scm 签出浅复制失败

Question

我正在使用 Jenkins 文件构建管道。我正在尝试使用 DSL 克隆参考存储库，如下所示。

checkout(
[$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, 
extensions: [[$class: 'CloneOption', depth: 1, noTags: false, reference: '', shallow: true]], 
submoduleCfg: [], 
userRemoteConfigs: [[url: '[email protected]:user_team/infrastructure-as-code.git']])

当管道正在执行时，它会被翻译成这样

git fetch --tags --progress [email protected]:userteam/infrastructure-as-code.git +refs/heads/*:refs/remotes/origin/* --depth=1

这会克隆我的 Jenkins 服务器上的整个存储库。我只想获得我的存储库的浅副本，以便我可以使我的 Jenkins 服务器免受空间紧张的影响。 请在这里帮忙。

我正在使用： 詹金斯版本：2.58，

插件：

流水线SCM步骤：2.4

Git：3.3.0

Answer 1

我认为你误解了浅克隆的含义。
浅克隆仍然会克隆整个存储库。
区别在于历史记录将被截断为指定的提交次数（在您的情况下为1，因为您已经提到深度为1。）它可以为您节省很多空间和时间。

欲了解更多信息，请点击此链接： git-clone#文档

例如，请参见下图，我将同一存储库（https://github.com/spring-cloud/spring-cloud-config.git）克隆两次，一次没有深度，一次深度=1。在第一种情况下，本地存储库大小为 40 MB，随着深度的增加，本地存储库大小仅为 3.4 MB。

Answer 2

我建议检查https://issues.jenkins-ci.org/browse/JENKINS-43878以更好地理解。该票证的记者比较了 3 种情况下克隆+签出过程的持续时间：使用 git 命令的非浅克隆、使用管道的浅克隆和使用 git 命令的浅克隆（深度=1），票证报告者抱怨情况 #2比案例 #3 持续时间长得多。

我使用存储库进行了https://github.com/tesseract-ocr/tessdata（~5 GB），但我无法重现持续时间差异。但我观察到了巨大的尺寸差异。这些是我的测量结果：

1. 带管道的完整克隆：8 分钟，总大小 4615 MB，“获取大小”3256 MB。
2. 使用“git clone”进行完整克隆：8 分钟，总大小 4615 MB。
3. 带有管道的浅克隆（深度=1）：4-5 分钟，总大小 3121 MB，“获取大小”1762 MB
4. 使用“git clone”进行浅克隆（深度=1）：4-5分钟，总大小1995 MB。

（我比较中的“fetch”大小是我在“git fetch”之后和“git checkout”之前在 Jenkins 管道的帮助下使用“du -ms”测量的目录大小）

如果比较案例 3 和 4，您会发现对于浅层克隆，管道（即“fetch+checkout”）方法会比普通“克隆”占用更多磁盘空间。

管道维护者同意这一事实，但以“不会修复”关闭了票证，因为他们不想由于其他原因将插件的工作方式从“获取+签出”更改为“克隆” .

这正是您问题的答案，为什么您看不到 Jenkins 管道的浅层克隆和完整克隆之间存在巨大差异：因为 Jenkins 管道使用“获取+签出”方法，在 --深度 的情况下，其工作方式与“克隆”和下载不同比“克隆”更多的数据。

如果您需要普通的“clone --深度”，则应将其作为管道脚本中的 shell 命令运行。在我看来，这是 Jenkins 管道的一个缺点。

Answer 3

我通过在克隆选项下添加

honorRefspec: true

并在

userRemoteConfig

中添加直接 refsec 来克服这个问题：

checkout(
    scm: scmGit(
        branches: [[name: '*/master']],
        extensions: [cloneOption(depth: 1, noTags: true, reference: '', shallow: true, honorRefspec: true)],
        userRemoteConfigs: [[
            refspec: '+refs/heads/master:refs/remotes/origin/master'
        ]]
    )
)