【问题标题】:How to specify depth in checkout(scm) in scripted pipeline如何在脚本管道中指定结帐(scm)的深度
【发布时间】:2019-10-03 06:12:24
【问题描述】:

我们的项目仓库非常大(2.5GB)。因此,在脚本化管道中的 checkout(scm) 步骤中,从 GIT 克隆代码需要更长的时间。由于 GIT 试图获取整个历史记录,我们正面临以下错误。

到目前为止我已经尝试过结帐(scm),我在https://jenkins.io/doc/pipeline/steps/workflow-scm-step/中读到 有一个名为 depth 的选项,通过它我们可以只下载最近的提交。

但我不知道它的语法。

node(nodeName) {
    try {
    deleteDir()
    checkout(scm)
        ....
        ....
    }
    catch(Exception ex) {
        throw ex
    }    
}

如果克隆时间减少,那将是非常有益的。 在执行 line checkout(scm) 时,

我们有时会收到以下错误。

using credential Servicejenkins_build
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository 
hudson.plugins.git.GitException: Command "C:\Git\cmd\git fetch --no-tags --progress https://gitlab.com/../../supportforpc.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: remote: Enumerating objects: 1           
remote: Enumerating objects: 24671, done.        
remote: Counting objects:   0% (1/24671)           
remote: Counting objects:   1% (247/24671)           
remote: Counting objects:   2% (494/24671)           
remote: Counting objects:   3% (741/24671)           
remote: Counting objects:   4% (987/24671)           
remote: Counting objects:   5% (1234/24671)           
remote: Counting objects:   6% (1481/24671)  
.....
....
Counting objects:   100% (24671/24671) 
remote: Compressing objects:   0% (1/10279)           
remote: Compressing objects:   1% (103/10279)           
remote: Compressing objects:   2% (206/10279)           
remote: Compressing objects:   3% (309/10279)           
remote: Compressing objects:   4% (412/10279)           
remote: Compressing objects:   5% (514/10279)           
remote: Compressing objects:   6% (617/10279)           
remote: Compressing objects:   7% (720/10279)           
remote: Compressing objects:   8% (823/10279)           
remote: Compressing objects:   9% (926/10279)           
remote: Compressing objects:  10% (1028/10279) 
....
....
remote: Compressing objects:  100% (10279/10279) 
Receiving objects:   0% (1/24671)   
Receiving objects:   1% (247/24671)   
Receiving objects:   2% (494/24671)   
Receiving objects:   3% (741/24671)   
Receiving objects:   4% (987/24671)   
Receiving objects:   5% (1234/24671)   
Receiving objects:   6% (1481/24671)
....
....
Receiving objects:   43%

    fatal: index-pack failed
    error: RPC failed; curl 56 SSL read: 
    error:00000000:lib(0):func(0):reason(0), errno 10054

因此我认为,在结帐(scm)中使用深度 1 可能会解决问题。但我不知道脚本管道中的语法。

【问题讨论】:

    标签: jenkins jenkins-pipeline jenkins-groovy


    【解决方案1】:

    您可以在结帐前在scm 对象中启用浅层克隆(无历史记录,仅获取最近的提交):

    node(nodeName) {
        try {
        deleteDir()
        scm.extensions << [$class: 'CloneOption', shallow: true]
        checkout(scm)
            ....
            ....
        }
        catch(Exception ex) {
            throw ex
        }    
    }
    

    但是,我建议您设置和维护一个参考存储库,它的速度要快一个数量级:

    1. 在终端窗口中,将您的存储库克隆到镜像中。此存储库将仅包含 git 对象:

      $ git clone --mirror https://gitlab.com/../../supportforpc.git
      Cloning into bare repository 'supportforpc.git'...
      remote: Enumerating objects: 6578, done.
      remote: Counting objects: 100% (6578/6578), done.
      remote: Compressing objects: 100% (1561/1561), done.
      remote: Total 739260 (delta 5791), reused 5046 (delta 5013), pack-reused 732682
      Receiving objects: 100% (739260/739260), 3.49 GiB | 3.78 MiB/s, done.
      Resolving deltas: 100% (562236/562236), done.
      
    2. 在 Jenkins 中创建一个新作业以定期更新镜像存储库。更新镜像时只使用fetch命令:

      sh "git fetch --all --prune"
      
    3. 告诉scm 对象使用镜像存储库作为参考。读取引用后查询远程存储库是否有新提交,因此您不必担心始终保持镜像最新:

      node(nodeName) {
          try {
          deleteDir()
          scm.extensions << [$class: 'CloneOption', reference: "<your-server>:git/<where-you-put-the-mirror-repo>"]
          checkout(scm)
              ....
              ....
          }
          catch(Exception ex) {
              throw ex
          }    
      }
      

    设置完成后,您会在几秒钟内看到您的整个存储库已被克隆,此外您还可以保留所有存储库的历史记录。如果您从步骤 1 中创建的镜像存储库手动克隆,您可以自己测试克隆:

    $ git clone <mirror-repository-directory> <some-dir>`
    Cloning into '<some-dir>'...
    done.
    Checking out files: 100% (15055/15055), done.
    

    关于修改默认scm 对象的说明:如果您不想更改它,可以为结帐创建一个新对象,如this answer 所示:

    checkout([
        $class: 'GitSCM',
        branches: scm.branches,
        doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
        extensions: scm.extensions + [$class: 'CloneOption', reference: "<your-server>:git/<where-you-put-the-mirror-repo>"],
        userRemoteConfigs: scm.userRemoteConfigs
    ])
    

    【讨论】:

    • 您将scm.extensions 行放在checkout 之前。 git 命令实际上是要在终端中运行,但 fetch 命令除外。我会更新答案。
    • 是的,谢谢。我希望在脚本管道中看到这些命令的示例。
    • 我还有一个大存储库 :) 完成镜像存储库后,我将粘贴克隆的输出。
    • 谢谢老兄,我会试试这个,看看几天,然后会支持这个答案。
    • 没关系 - 仅在您认为有帮助的情况下投票。对于我的用例,参考存储库效果很好,但对其他人来说可能不是这样。
    【解决方案2】:
    checkout changelog: false, poll: false, scm: [$class: 'GitSCM', branches: [[name: '*/branchname'], [$class: 'CloneOption', depth: 1, noTags: true, reference: '', shallow: true]], userRemoteConfigs: [[credentialsId: 'credentialId', url: 'git@repourl']]]
    

    credentialId 可以通过点击 http://yourjenkinsinstall/credentials 找到

    【讨论】:

    • 这导致no known implementation of interface java.util.List is named CloneOption。因为您将 CloneOption 传递给 branches 参数。 jenkins.io/doc/pipeline/steps/workflow-scm-step 的文档指出 CloneOption 被传递给 extensions 参数。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多