-
Bug
-
Resolution: Duplicate
-
Critical
-
Windows 2012 R2
Jenkins 2.7.4
Git Client Plugin 2.5.0
Git Plugin 3.5.1
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes.
We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at.
Here is our Git polling log output:
Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@********.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@********.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@********.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10
I've attached a screenshot of the job's Git settings.
I've tried leaving the "branch" field blank and using refs/heads/**. Same result.
- duplicates
-
JENKINS-45447 Git checkout with many tags is much slower with 3.3.0 release if pre-build merge is used
-
- Closed
-
[JENKINS-47169] SCM polling runs rev-parse for every tag
Description |
Original:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. |
New:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. Here is our Git polling log output: {code:java} Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10{code} |
Assignee | Original: Mark Waite [ markewaite ] |
Description |
Original:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. Here is our Git polling log output: {code:java} Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@whsbitbucket.webmd.net:7999/automation/depot.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10{code} |
New:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. Here is our Git polling log output: {code:java} Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@********.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@********.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@********.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10{code} I've attached a screenshot of the job's Git settings. |
Link |
New:
This issue duplicates |
Attachment | New: JenkinsDepotGitSettings.png [ 39877 ] |
Description |
Original:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. Here is our Git polling log output: {code:java} Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@********.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@********.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@********.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10{code} I've attached a screenshot of the job's Git settings. |
New:
Whenever the git plugin checks for changes, it runs git rev-parse for every tag in a repository. We have a hundred jobs or so, all of which have many tags. This causes the check for new changes to take longer than a minute. Our builds are configured to check for changes every minute. The net result is that Jenkins is spending all its time/CPU checking for changes. We upgraded to the latest version of each plugin yesterday. I don't remember what version we were at. Here is our Git polling log output: {code:java} Started on Sep 27, 2017 2:05:03 PM Polling SCM changes on master Using strategy: Default [poll] Last Built Revision: Revision 6d88077c1ed8fea0a847c1ce81dc4a7c693b6d3c (origin/master) > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git.exe config remote.origin.url ssh://git@********.git # timeout=10 Cleaning workspace > git.exe rev-parse --verify HEAD # timeout=10 Resetting working tree > git.exe reset --hard # timeout=10 > git.exe clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from ssh://git@********.git > git.exe --version # timeout=10 > git.exe fetch --tags --progress ssh://git@********.git +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git.exe tag -l # timeout=10 > git.exe rev-parse "refs/tags/0.1.1^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.2^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.0^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.10^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.9^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/Dev^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.5^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.3^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.1.4^{commit}" # timeout=10 > git.exe rev-parse "refs/tags/0.2.4^{commit}" # timeout=10{code} I've attached a screenshot of the job's Git settings. I've tried leaving the "branch" field blank and using {{refs/heads/**}}. Same result. |
Resolution | New: Duplicate [ 3 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |