-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
-
git plugin 4.4.0
When hasGitRepo is false, retrieveChanges() tries firstly to Clone repository and then fetch according to available list of repositories.
https://github.com/jenkinsci/git-plugin/blob/e9d15cd3a390f1d1849b9d6cbee707bc85213ab0/src/main/java/hudson/plugins/git/GitSCM.java#L1104-L1110
But when it clones it picks first repository name and injects ALL branches fetch https://github.com/jenkinsci/git-client-plugin/blob/2b217bd90a93462112176febbb5f30e05141c674/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L704-L712
So, when refspecs is empty - it fetch all branches (git default), when it null it fetches all branches.
The workaround is to set some refspec from branch i.e. https://github.com/jenkinsci/git-plugin/blob/a7ad6eb38a00397c4a656b53d99bfbad8ea3b2cc/src/main/java/jenkins/plugins/git/GitSCMSourceDefaults.java#L108-L115
But, later it will be fetched anyway.
Solution:
Don't fetch anything during clone operation (useful part is clean, fetch etc). OR pass repositories to CloneComand and remove separate fetch iteration .
- is related to
-
JENKINS-49757 Git plugin calls fetch twice per checkout
-
- Closed
-
-
JENKINS-23345 Git Plugin should have an option to use clone instead of init/fetch
-
- Closed
-
As far as I can tell from testing, when a refspec is defined and the clone option "honor refspec on inital clone" is enabled, the refspec is honored in both fetches that occur. Do you have a case where the clone option "honor refspec on initial clone" is not having the desired result?
It is an intentional choice to retain compatibility with the existing (flawed) behavior of using a default refspec which fetches all branches. Too many users depend on fetching all branches without realizing they have that dependency. If the default behavior were changed, they would need to adjust the definitions of those jobs.
Multibranch pipeline intentionally changed its behavior relatively early in development. Originally it used the default refspec for each job defined by the multibranch pipeline. A breaking change was accepted that uses a narrow refspec for exactly the branch dedicated to the specific job. Even that early stage breaking change caused some challenges for user, but the challenge was considered worth it due to the savings provided to multibranch pipeline jobs by the narrow refspec.