Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
Windows (8) (the slow disk access probably makes it more likely to manifest)
Description
Some git processes error out with ERROR: Timeout after 10 minutes even though longer timeout is configured in the job.
It affects the `git checkout` operation itself. The fetch operation is OK.
The log says:
using GIT_SSH to set credentials jenkins key for git > git fetch --tags --progress git@git.company.com:project +refs/heads/*:refs/remotes/origin/* --prune Checking out Revision 159bc2b21669bc7b5217341fc8de9cd6b48439b2 (origin/dev/jan.hudec/pu) > git config core.sparsecheckout > git checkout -f 159bc2b21669bc7b5217341fc8de9cd6b48439b2 ERROR: Timeout after 10 minutes FATAL: Could not checkout null with start point 159bc2b21669bc7b5217341fc8de9cd6b48439b2
When I manually removed the lock and repeated the checkout operation, it indeed took 11 minutes 15 seconds on the node where it failed.
The global timeout does work, so it's not a blocker anymore. It is, however, rather non-obvious configuration as the -Dorg.jenkinsci.plugins.gitclient.Git.timeOut=30 (or whatever sufficiently large value) option needs to be added to both JVM options of the master and JVM options of all slaves. The master options can only be configured in the servlet container and while the slave options can be configured in node settings (hidden out under "Advanced" button), slaves running as windows service don't take this into account without reinstalling the service.
Attachments
Issue Links
- duplicates
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
Activity
vadivel the bug was fixed over 2 years ago. and is as described by knighttp01 in the comment above your comment that you're reopening the bug.
It is not enough to say "the same issue occurring". You'll need to provide much more context than "same issue occurring". What have you tried? What is the context where timeouts are not behaving as you expect? What is the log content when the timeout does not behave as you expect? What job type are you using?
Please gather those details and submit a new bug report, rather than reopening this report.
There are many, many users that are successfully using extended timeouts to clone and checkout large repositories. I've presented talks at Jenkins World 2016, Jenkins World 2017,at a 2016 online meetup and at a 2017 online meetup that describe techniques to better manage large repositories. All of those talks depend on adjusting timeout values as needed, and they work.
In addition to those resources, CloudBees support has provided detailed instructions for configuring a reference repository to speed clone operations.
Seems resolved by this way: set timeout by "CloneOption"
checkout scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CloneOption', timeout: 240]], // CheckoutOption -> CloneOption gitTool: 'Default', submoduleCfg: [], userRemoteConfigs: [[ credentialsId: '981cbff3-3a30-4a61-be40-99f441ea0559', url: 'git@server:project.git' ]]]
Yarden Bar
added a comment - Hi,
We encountered this timeout as well, but we suspect that the git config core.sparsecheckout with out explicit true argument causes this.
Adding the CloneOption with timeout didn't help in our case.
Is there a way to configure git config core.sparsecheckout true in the checkout step? I've read the documentation but coudn't figure out how to do so...
Thank you,
Yarden
Yarden Bar
added a comment - Hi,
We encountered this timeout as well, but we suspect that the git config core.sparsecheckout with out explicit true argument causes this.
Adding the CloneOption with timeout didn't help in our case.
Is there a way to configure git config core.sparsecheckout true in the checkout step? I've read the documentation but coudn't figure out how to do so...
Thank you,
Yarden judgedredd it is generally considered bad form to ask an unrelated question in a bug report. It clutters the bug reports and wastes the time of maintainers that are notified when the unrelated comment is added to the bug report. Please don't do that in the future. Use the mailing list or chat questions and answers so that more than a few people are notified and might be able to assist.
The question interested me enough that I added it to my JENKINS-52746 test case. Refer to that example for details that will allow you to use a sparse checkout path definition in a declarative Pipeline checkout statement.
If you are using declarative Pipeline, you may also need to `skipDefaultCheckout(true)` in the options section, otherwise the full repository checkout happens implicitly before the first step.
Yes - adding an "advanced clone behavior" and then setting the timeout there solved my problem.