-
Bug
-
Resolution: Fixed
-
Major
-
Windows (8) (the slow disk access probably makes it more likely to manifest)
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.
- duplicates
-
JENKINS-20387 git submodule update timeout value should be configurable per job
- Closed
-
JENKINS-37185 Checkout timeout is not honored when used with local branch parameter
- Closed
- is related to
-
JENKINS-11286 Git plugin does not timeout
- Closed
-
JENKINS-20445 Git plugin timeout is too small
- Closed