-
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
created issue -
Nenad Miksa
made changes -
| Component/s | New: workflow-multibranch-plugin [ 21465 ] |
| Assignee | Original: Mark Waite [ markewaite ] |
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.
| Workflow | Original: JNJira [ 173276 ] | New: JNJira + In-Review [ 185037 ] |
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.
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.