Details
-
Type:
Improvement
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: git-client-plugin
-
Labels:None
-
Similar Issues:
Description
We have issues with jobs that fail on git timeout. Current git-client version allow to configure timeout for clone and fetch command. However, I see issues with 'git clean' command also. The problem mainly occurs on our windows slaves. Heavy load on virtual machines tend affect file system actions...
I would like to be able to set the default git timeout (globally if possible).
Not really sure if this is a bug or improvement.
Attachments
Issue Links
- is duplicated by
-
JENKINS-39111 Git client timeout for checkout operation should be applied to git clean
-
- Open
-
- is related to
-
-
- Open
-
Activity
Is this going to be added for reset as well?
> git reset --hard # timeout=10 ERROR: Timeout after 10 minutes
trejkaz
added a comment - Is this going to be added for reset as well?
> git reset --hard # timeout=10
ERROR: Timeout after 10 minutes
trejkaz I am not planning to add timeout adjustment support for git reset --hard. I'm impressed that you've found a case where it requires more than 10 minutes to complete. Can you provide more details on the environment where you see git reset --hard require more than 10 minutes?
I assume it is a large git repository accessed over a network file system with many changes to tracked files in the working directory. How large is the repository? How widespread are the changes? How does the file system perform in general?
It's a large repo but the filesystem is local.
The only thing could be that Jenkins is often introducing contention with itself - when it scans a repo for new branches to build, it immediately kicks off builds for the branches it finds, which all require checkouts done on the master, which then all run at the same time, making all of them run slower.
As far as changes to tracked files, there wouldn't be any changes done by ourselves, but Jenkins might have done something as part of doing the merge between master and whatever branch it's building.
trejkaz
added a comment - - edited It's a large repo but the filesystem is local.
The only thing could be that Jenkins is often introducing contention with itself - when it scans a repo for new branches to build, it immediately kicks off builds for the branches it finds, which all require checkouts done on the master, which then all run at the same time, making all of them run slower.
As far as changes to tracked files, there wouldn't be any changes done by ourselves, but Jenkins might have done something as part of doing the merge between master and whatever branch it's building.
I'm impressed that you've found a case where it requires more than 10 minutes to complete.
Large repo + interrupted checkout during previous build == almost all I/O happens during git reset --hard. If you add LFS to the mix, that I/O also involves transferring files over network.
Simpler way to reproduce: just remove everything from working copy, but keep .git it in. Voila, you've got a massive git reset --hard for next build in the same working copy.
Marat Radchenko
added a comment - - edited I'm impressed that you've found a case where it requires more than 10 minutes to complete.
Large repo + interrupted checkout during previous build == almost all I/O happens during git reset --hard . If you add LFS to the mix, that I/O also involves transferring files over network.
Simpler way to reproduce: just remove everything from working copy, but keep .git it in. Voila, you've got a massive git reset --hard for next build in the same working copy. 
Gotcha - I completely missed that. As you say, I thought the clone&fetch button included the checkout too. Didn't read it carefully. Thanks for helping out.