Jenkins checkout在10分钟后计时结束

Question

我有一个管道，我用git插件执行一个签出步骤。

由于超时问题，checkout步骤在10分钟后失败。

经过我的研究，我发现git插件的默认超时值是10分钟(正是我的问题)

经过进一步的研究，我发现你可以用一个扩展名来修改这个时间，像这样:

Map checkout_settings = [
changelog: true,
scm: [
$class: 'GitSCM',
userRemoteConfigs: [
[
credentialsId: ((Map) settings.credentials)?.id?.toString()?.trim() 
url: sttings.scmUrl.toString().trim()
]
],
branches: [branch],
extensions: [
[
$class: 'CheckoutOption',
timeout: 70
],
[
$class: 'CloneOption',
timeout: 70,
shallow: true,
depth: 1,
noTags: true
],
[
$class: 'RelativeTargetDirectory',
relativeTargetDir: settings.executeFrom?.toString()?.trim() ?: ''
],
[
$class: 'SubmoduleOption',
disableSubmodules: ((Map) settings.submodules)?.checkout != 'all' ?: false,
parentCredentials: true,
recursiveSubmodules: ((Map) settings.submodules)?.recursive ?: false,
timeout: 70
],
[
$class: 'ScmName',
name: settings.scmName?.toString()?.trim() ?: settings.scmUrl.toString().trim()
]
]
]
]

我将克隆和签出选项设置为70分钟的超时，并简单地将这些设置发送到签出步骤。

checkout(checkout_settings)

我希望这能解决我的问题，但我的问题仍然存在，正如你可以从下面的日志中看到的:

The recommended git tool is: NONE
using credential sshkey
Cloning the remote Git repository
Using no checkout clone with sparse checkout.
Cloning repository ssh://[e-mail]/lww/ekkjp-sp2013-responsive.git
> git init F:wsEJPEJP-CoreCoreEJP_Core1631 # timeout=10
Fetching upstream changes from ssh://[e-mail]/lww/ekkjp-sp2013-responsive.git
> git --version # timeout=10
> git --version # 'git version 2.30.0.windows.2'
using GIT_SSH to set credentials 
> git fetch --tags --force --progress -- ssh://[e-mail]/lww/ekkjp-sp2013-responsive.git +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- ssh://[e-mail]/lww/ekkjp-sp2013-responsive.git +refs/heads/*:refs/remotes/origin/*" returned status code 130:

结帐开始，并持续一段时间，直到出现以下情况:

Receiving objects:  84% (258842/307384), 896.07 MiB | 11.99 MiB/s
Receiving objects:  84% (258842/307384), 909.63 MiB | 12.53 MiB/s
Receiving objects:  84% (259843/307384), 927.31 MiB | 12.55 MiB/s
The process tried to write to a nonexistent pipe.
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2639)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2079)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:84)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:601)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:830)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:376)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:119)
at java.lang.Thread.run(Thread.java:829)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from 10.234.12.21/10.234.12.21:49686
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
at hudson.remoting.Channel.call(Channel.java:1001)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor823.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy167.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1223)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1301)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)

仍然超时10分钟。我错过了什么?

Answer 1

这意味着它不是在Jenkins级别必须设置超时。
Jenkins主控制器需要通过SSH访问远程Git存储库托管服务器(在你的例子中是bitbucket.trt.io)。检查SSH设置，如下所示:

检查笔记本电脑中的/etc/ssh/ssh_config文件(系统范围的ssh配置)和~/.ssh/config文件(用户的ssh配置)，并查看是否有为ServerAliveInterval和ServerAliveCountMax(Host *或Host bitbucket.trt.io)设置的值。

如果您在两个文件中都没有看到这些选项，您可以做的是在两个文件中添加以下内容来保持连接打开更长时间:

Host bitbucket.trt.io
ServerAliveInterval 300
ServerAliveCountMax 2

上面的值只是一个例子，你可以根据钩子需要完成的时间来调整它们。
这些设置将使您的SSH客户端每300秒(5分钟)向Bitbucket发送一个空数据包，如果在2次尝试后没有收到响应，则放弃。这将在连接超时之前为您提供10分钟的时间，如果钩子需要更长的时间才能完成，您可以为其中一个或两个选项设置更高的值。

对你来说，~/.ssh/config就是/home/<the-account-used-by-Jenkins>/.ssh/config。

Answer 2

你可以将checkout()调用封装在超时块中，以覆盖默认的Jenkins超时

timeout(time: 30, unit: 'MINUTES') {
def checkout_values = checkout(checkout_settings)
}

类似于这个例子:如何使构建超时在詹金斯管道groovy脚本?