-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Git Plugin 4.4.3
Jenkins 2.249.1
CentOS 7
Hello,
First, thank you for maintaining and developing this nice Git plugin!
Recently, I got some issues with some jobs using a wrong refspec to build. This only happened recently for jobs doing a "frech clone" and I suspect, only after an update of the Git Plugin.
I don't have the issue when enabling "Preserve second fetch during checkout" option from PR-845 (JENKINS-49757).
Maybe what is particular on my side is that there are multiple branches in my repo and my refspec contains 'refs/heads' ("refs/heads/mptcp_trunk/master"). From what I see in PR-845, that's why the second fetch is not done but I don't know why it is an issue to add 'refs/heads' in the refspec. When I look at what is done by Jenkins, it looks like I could only add the name of the branch but if I have not to specified 'refs/heads', I am confused with the option name and the description
Also, I didn't set anything related to "Advanced Clone Option" as mentioned in the doc because I didn't find the corresponding option in the config (and to be honest, I don't know why I would like to do the clone and the fetch later differently ).
(Note: I added "origin/" in the branch name just to try but it didn't help. Just to explain why we see a reference to "origin/xxx" in the logs)
Here are the logs without "Preserve second fetch during checkout" option:
> git fetch --tags --progress ssh://gerrit:29418/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url ssh://gerrit:29418/repo.git # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 Avoid second fetch > git rev-parse FETCH_HEAD^{commit} # timeout=10 Checking out Revision 5ac0ebcbb890f2a7852bca357641163837a219bd (origin/mptcp_trunk/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 5ac0ebcbb890f2a7852bca357641163837a219bd # timeout=10 Commit message: "old commit"
Here, you can see that all branches are fetches but then FETCH_HEAD is used with git checkout which is not correct: FETCH_HEAD corresponds to the first branch by alphabetical order on the remote (because we asked for refs/heads/*).
Now here is the output with "Preserve second fetch during checkout" on:
> git fetch --tags --progress ssh://gerrit:29418/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url ssh://gerrit:29418/repo.git # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url ssh://gerrit:29418/repo.git # timeout=10 Fetching upstream changes from ssh://gerrit:29418/repo.git using GIT_SSH to set credentials > git fetch --tags --progress ssh://gerrit:29418/repo.git refs/heads/mptcp_trunk/master +refs/heads/mptcp_trunk/master:refs/remotes/origin/mptcp_trunk/master # timeout=10 > git rev-parse FETCH_HEAD^{commit} # timeout=10 Checking out Revision 21ec2388799b5bd7e18f3f2bd4aa7f0e2be9bb23 (origin/mptcp_trunk/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 21ec2388799b5bd7e18f3f2bd4aa7f0e2be9bb23 # timeout=10 Commit message: "new commit"
FETCH_HEAD is now corresponding to refs/heads/mptcp_trunk/master, what I want: then everything is OK.
I hope this will help finding the issue not to have to enable "Preserve second fetch during checkout" option.
Thanks for reporting the issue. It looks like you've found a case that is missed in our logic to decide if the second fetch is required. Could you upload the config.xml for your job definition and / or the checkout step that is being performed (if this is a Pipeline job).
I suspect that the job is configured with multiple repositories or with multiple refspecs and the plugin is not handling that correctly. We'll need the job details to assure that we can duplicate the problem and provide a fix. In this case, I expect that there is a way that the job can be redefined so that it does not require the second fetch. Whether there is or not, this is a case where the second fetch is required and the plugin did not detect that the second fetch is required. Sorry we missed that!