mur*_*thi 8 jenkins jenkins-groovy jenkins-pipeline
我们的项目仓库非常大(2.5GB)。因此,在脚本化管道中的 checkout(scm) 步骤中,代码需要更长的时间从 GIT 克隆。由于 GIT 试图获取整个历史记录,我们面临以下错误。
到目前为止,我已经尝试过 checkout(scm),我在https://jenkins.io/doc/pipeline/steps/workflow-scm-step/中读到 ,有一个名为“深度”的选项,通过它我们只能下载最近的承诺。
但我不知道它的语法。
node(nodeName) {
try {
deleteDir()
checkout(scm)
....
....
}
catch(Exception ex) {
throw ex
}
}
Run Code Online (Sandbox Code Playgroud)
如果克隆时间减少,那将是非常有益的。执行线路结账(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
Run Code Online (Sandbox Code Playgroud)
因此我认为,在 checkout(scm) 中使用深度 1 可能会解决这个问题。但我不知道脚本化管道中的语法。
scm您可以在签出之前在对象中启用浅克隆(没有历史记录,仅获取最近的提交) :
node(nodeName) {
try {
deleteDir()
scm.extensions << [$class: 'CloneOption', shallow: true]
checkout(scm)
....
....
}
catch(Exception ex) {
throw ex
}
}
Run Code Online (Sandbox Code Playgroud)
但是,我建议您建立并维护一个参考存储库,这会快一个数量级:
在终端窗口中将您的存储库克隆到镜像中。该存储库将仅包含 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.
Run Code Online (Sandbox Code Playgroud)在 Jenkins 中创建一个新作业来定期更新镜像存储库。fetch更新镜像时仅使用命令:
sh "git fetch --all --prune"
Run Code Online (Sandbox Code Playgroud)告诉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
}
}
Run Code Online (Sandbox Code Playgroud)设置完成后,您将看到整个存储库在几秒钟内就被克隆,而且您还可以保留所有存储库的历史记录。如果您从步骤 1 中创建的镜像存储库手动克隆,您可以自己测试克隆:
$ git clone <mirror-repository-directory> <some-dir>`
Cloning into '<some-dir>'...
done.
Checking out files: 100% (15055/15055), done.
Run Code Online (Sandbox Code Playgroud)
关于修改默认scm对象的注意事项:如果您不想更改它,您可以为结账创建一个新对象,如本答案所示:
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
])
Run Code Online (Sandbox Code Playgroud)