Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-36563

Git plugin does not fetch branch to merge to when merge before build is used

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Blocker Blocker
    • git-plugin, workflow-multibranch-plugin
    • 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.

          [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)?

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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?

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

            Unassigned Unassigned
            dodoent Nenad Miksa
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: