[JENKINS-47169] SCM polling runs rev-parse for every tag

Type: Bug
Resolution: Duplicate
Priority: Critical
Component/s: git-plugin
Labels:
- git-client
- git-plugin
Environment:
Windows 2012 R2
Jenkins 2.7.4
Git Client Plugin 2.5.0
Git Plugin 3.5.1

Similar Issues:
Powered by SuggestiMate

Show

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.

- - Sort By Name
  - Sort By Date
  - Ascending
  - Descending
  - Thumbnails
  - List
  - Download All

JenkinsDepotGitSettings.png
2017-09-27 21:11
28 kB
Aaron Jensen

duplicates

JENKINS-45447 Git checkout with many tags is much slower with 3.3.0 release if pre-build merge is used

Closed

Aaron Jensen created issue - 2017-09-27 20:56

Aaron Jensen made changes - 2017-09-27 21:08

Description

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}

Mark Waite made changes - 2017-09-27 21:08

Assignee

Original: Mark Waite [ markewaite ]

Aaron Jensen made changes - 2017-09-27 21:10

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.

Mark Waite added a comment - 2017-09-27 21:11 - edited

Your best short term solution is to downgrade the git plugin. One of the unintended side effects of a change in git plugin 3.3.0 (I believe) was to dramatically increase the number of calls to git rev-parse. Refer to ~~JENKINS-45447~~ for more details.

Another alternative may be to add the advanced clone option to your jobs to not fetch tags.

Mark Waite added a comment - 2017-09-27 21:11 - edited Your best short term solution is to downgrade the git plugin. One of the unintended side effects of a change in git plugin 3.3.0 (I believe) was to dramatically increase the number of calls to git rev-parse. Refer to JENKINS-45447 for more details. Another alternative may be to add the advanced clone option to your jobs to not fetch tags.

Mark Waite made changes - 2017-09-27 21:11

Link

New: This issue duplicates ~~JENKINS-45447~~ [ ~~JENKINS-45447~~ ]

Aaron Jensen made changes - 2017-09-27 21:11

Attachment

New: JenkinsDepotGitSettings.png [ 39877 ]

Aaron Jensen made changes - 2017-09-27 21:12

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.

Aaron Jensen added a comment - 2017-09-27 21:28

Downgrading to 3.0.0 of the Git plugin fixed this problem.

Aaron Jensen added a comment - 2017-09-27 21:28 Downgrading to 3.0.0 of the Git plugin fixed this problem.

Mark Waite made changes - 2017-09-27 23:45

Resolution		New: Duplicate [ 3 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]

Assignee:: Unassigned

Reporter:: Aaron Jensen

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Created:: 2017-09-27 20:56

Updated:: 2017-12-18 14:15

Resolved:: 2017-09-27 23:45

Jenkins

Details

Description

Attachments

Attachments

Issue Links

Activity

Collapse comment: Mark Waite added a comment - 2017-09-27 21:11, Edited by Mark Waite - 2017-09-27 21:13

Expand comment: Mark Waite added a comment - 2017-09-27 21:11, Edited by Mark Waite - 2017-09-27 21:13

Collapse comment: Aaron Jensen added a comment - 2017-09-27 21:28

Expand comment: Aaron Jensen added a comment - 2017-09-27 21:28

People

Dates