This was originally discussed in the comments of
JENKINS-26587 as it was first identified as a regression when testing that issue. As Git Plugin 2.4.1 has how been release w/o resolving this regression, it has escaped and I am opening a separate ticket.
Previously in (and correctly?) when using the "Prune stale remote-tracking branches" behavior, in every build, after the git checkout -f but before the git reset --hard there was a git rev-parse --verify HEAD command. Now in place of the single rev-parse command there is a git rev-parse /remotes/origin/... command for every remote branch that exists.
- Install a baseline Jenkins Master, which will include the Git Plugin v 2.4.1. (We used the 1.625.3 LTS version.)
- Setup credentials so that it can authenticate to a remote repo. (We use Atlasssian Stas.h.
- Create a freestyle job to pull from a remote git repo that has multiple (preferably many) branches.
- branch specifier origin/master
- Additional Behaviors: Prune stale remote-tracking branches.
Run the job and observe the output. It will be something similar to the following:
With 17K+ remote branches in our repository, this added fifteen minutes to builds that previously took three to eight minutes total. Obviously we could stand to clean up some old branches but this behavior is not acceptable.
- Remove the prune stale branches behavior.
- Downgrade to Git Plugin 2.4.0