-
Bug
-
Resolution: Cannot Reproduce
-
Blocker
-
None
-
ArchLinux, Jenkins 2.48, Git Plugin 3.0.5, Git Client Plugin 2.2.1
I am using MultiBranch Pipeline and performing git cloning like this when I detect in script that this build is building a PullRequest:
try { checkout([ $class: 'GitSCM', branches: scm.branches, doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations, extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: false, depth: 0, timeout: 60], [$class: 'PruneStaleBranch'], [$class: 'CheckoutOption', timeout: 60], [$class: 'SubmoduleOption', recursiveSubmodules: true, timeout: 60], [$class: 'PreBuildMerge', options: [mergeRemote: 'origin', mergeTarget: targetBranch, fastForwardMode: ffMode]]], submoduleCfg: [], userRemoteConfigs: scm.userRemoteConfigs, browser: [$class: 'BitbucketWeb', repoUrl: 'https://bitbucket.org/microblink/core'] ]) } catch (error) { currentBuild.result = 'FAILURE' echo "ERROR: Cannot perform git checkout due to git error or because branch does not merge cleanly!, Reason: '${error}'" sh 'false' }
scm is global variable defined by Multibranch Pipeline plugin and targetBranch is variable containing branch to which pull request is to (in my case this is 'master'). ffMode variable is set to 'FF_ONLY'
This used to work two weeks ago, and now it stopped with following error:
hudson.plugins.git.GitException: Command "git rev-parse origin/master^{commit}" returned status code 128: stdout: origin/master^{commit} stderr: fatal: ambiguous argument 'origin/master^{commit}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'
Indeed, if I cd into jenkins build dir on server and execute this command, I get the same error. Furthermore, If I execute 'git branch -a', I see no branches being fetched.
This used to work before, but recently it stopped. Unfortunately, I cannot tell whether it stopped working due to update of jenkins, git plugin or git client plugin - downgrading any of it does not remove the issue.
EDIT: This issue was fixed in v2.6.0, but reappeared in v3.0.0 and is still here in v3.0.5.
- duplicates
-
-
- Closed
-
[JENKINS-36563] Git plugin does not fetch branch to merge to when merge before build is used
Nenad Miksa
added a comment - In failing repositories,
git branch -a
returns empty list (I mentioned that in original report).
Downgrading git-plugin to 2.5.0 did not help, although I haven't tried wiping the workspace after downgrade. I'll try that ASAP.
Nenad Miksa
added a comment - In failing repositories,
git branch -a
returns empty list (I mentioned that in original report).
Downgrading git-plugin to 2.5.0 did not help, although I haven't tried wiping the workspace after downgrade. I'll try that ASAP. Nenad Miksa
added a comment - Running git config --get remote.origin.fetch returns +refs/heads/feature/my-feature-branch. I believe this is wrong.
Nenad Miksa
added a comment - Running git config --get remote.origin.fetch returns +refs/heads/feature/my-feature-branch . I believe this is wrong. Nenad Miksa
added a comment - OK, after downgrading to v2.5.0 and wiping the workspace I can confirm that merge before build now works. As you said, the change introduced in v2.5.1 introduced the issue.
Any known workarounds (except preventing upgrade of git plugin)?
Nenad Miksa
added a comment - OK, after downgrading to v2.5.0 and wiping the workspace I can confirm that merge before build now works. As you said, the change introduced in v2.5.1 introduced the issue.
Any known workarounds (except preventing upgrade of git plugin)? One work around with the current plugins is to switch from using the non-default refspec you're currently using +refs/heads/feature/my-feature-branch to the default refspec that your merge process seems to assume is needed. At minimum, the refspecs need to include both the source branch and the target branch. You can include multiple refspecs in the repository definition by separating them with spaces. Or, you can clear the refspec field so that it will use the default refspec.
The refspec is retained from the initial clone, so changing the refspec will require that you wipe the workspace.
Please check with git plugin 2.5.3, released 30 July 2016. It implemented JENKINS-36507 to return to ignoring the refspec on initial clone. That should fix this bug.
Fixed in git plugin 2.5.3 by restoring the default behavior of ignoring the refspec on initial clone. Refer to JENKINS-36507 for the rationale of that change.
Nenad Miksa
added a comment - In v2.6.0 this worked OK and was fixed, but it seems that there is a regression in v3.0.0, as we are experiencing the same bug again after updating to v3.0.0. Reverting back to v2.6.0 solves the problem for us.
Nenad Miksa
added a comment - In v2.6.0 this worked OK and was fixed, but it seems that there is a regression in v3.0.0, as we are experiencing the same bug again after updating to v3.0.0. Reverting back to v2.6.0 solves the problem for us. Nenad Miksa
added a comment - This issue was resolved in v2.5.3 and was not there in v2.6.0, however it reappeared in v3.0.0 and is still present in v3.0.5.
Are there any options to tell git from pipeline script to always fetch all?
Nenad Miksa
added a comment - This issue was resolved in v2.5.3 and was not there in v2.6.0, however it reappeared in v3.0.0 and is still present in v3.0.5.
Are there any options to tell git from pipeline script to always fetch all? The git plugin fetches all refspecs unless you specifically declare honorRefSpec: true as a CloneOption. Since your job definition does not declare honorRefSpec: true, I'm reasonably confident that the refspec is being cloned.
You might check to see if someone inadvertently created a branch named "origin/master" in your repository. That is one way to confuse the git rev-parse command. I suspect that isn't the case, since that would also have confused git plugin 2.6.0. Unfortunately, that's the only idea that comes to mind.
Nenad Miksa
added a comment - Hi markewaite,
thank you for pointing that out. I've now explicitely added `honorRefspec: false` to my clone option as a precaution for case if multibranch-pipeline sets it as true. Hopefully I won't have merge before build issues anymore now - If I will, I will reopen this issue.
Nenad Miksa
added a comment - Hi markewaite ,
thank you for pointing that out. I've now explicitely added `honorRefspec: false` to my clone option as a precaution for case if multibranch-pipeline sets it as true. Hopefully I won't have merge before build issues anymore now - If I will, I will reopen this issue. 
In one of the failing repositories, could you run the command git branch -a? It will probably show that there is no branch named remotes/origin/master.
In one of the failing repositories, could you run the command git config --get remote.origin.fetch? It may show that the refspec is something other than the default (though I don't see anything in your pipeline definition which would indicate you're using a non-default refspec).
The default refspec is
Those questions are all attempting to detect if the failure to parse the origin/master reference is a side effect of the fix for
JENKINS-31393which was introduced in 2.5.1. If you are able to roll-back your git plugin to 2.5.0 and wipe the workspace for those builds, that may tell us if that is the cause.