我有一个管道，我用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()
]
]
]
]我将clone和checkout选项设置为超时70分钟，然后将这些设置发送到checkout步骤。
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://git@bitbucket.trt.io/lww/ekkjp-sp2013-responsive.git
> git init F:\ws\EJP\EJP-Core\Core\EJP_Core\1631 # timeout=10
Fetching upstream changes from ssh://git@bitbucket.trt.io/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://git@bitbucket.trt.io/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://git@bitbucket.trt.io/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)十分钟后还是超时了。我错过了什么？
2条答案
按热度按时间omjgkv6w1#
这意味着它不是在Jenkins水平的超时必须设置。
Jenkins主控制器需要通过SSH访问远程Git仓库托管服务器（在您的例子中为
bitbucket.trt.io）。检查笔记本电脑中的文件
/etc/ssh/ssh_configfile（系统范围的ssh配置）和~/.ssh/config（您的用户的ssh配置），并查看是否为ServerAliveInterval和ServerAliveCountMax设置了任何值（Host *或Host bitbucket.trt.io）。如果在这两个文件中没有看到这些选项，则可以在其中一个文件中添加以下内容，以使连接保持更长时间的打开状态：
上面的值只是一个例子，你可以根据你的钩子需要完成多久来调整它们。
这些设置会让你的SSH客户端每隔300秒（5分钟）发送一个空数据包到Bitbucket，如果2次尝试后没有收到响应，就给予。这会给你10分钟的时间连接超时，如果钩子需要更长的时间才能完成，你可以设置一个更高的值给其中一个或两个选项。
对你来说，
~/.ssh/config意味着/home/<the-account-used-by-Jenkins>/.ssh/config。oo7oh9g92#
您可以将checkout（）调用 Package 在一个timeout块中，以便覆盖缺省的Jenkins超时
与此示例类似：如何在jenkins pipeline groovy脚本中设置构建超时？