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

scm.branches points to a wrong branch name with Git Plugin 4.4 and multibranch pipeline

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Incomplete
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Jenkins 2.249.1
      Git plugin 4.4.1
      Pipeline: SCM Step 2.11
      CentOS 7 x86_64 (master and slaves)
      OpenJDK 1.8 (master and slaves)
      Slaves are launched via SSH
    • Similar Issues:

      Description

      Greetings,

      We have issues with Git Plugin 4.4 and multibranch pipelines, as scm.branches now points to the PR number and not to the actual branch name of the PR. E.g. we used the following snippet earlier:

      checkout([
          $class: 'GitSCM',
          branches: scm.branches,
          userRemoteConfigs: [[
            credentialsId: 'foo',
            url          : 'git@github.com:foo/bar.git'
          ]],
          extensions       : [[
            $class: 'CloneOption',
            noTags: false,
            shallow: false
          ]]
        ])
      

      Now, as scm.branches has e.g. '[PR-1234]' value instead of '[branch-name]', build fails with the ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

      Issue was verified with 1 GitHub repository, cannot reproduce with BitBucket.

      Also, I couldn't find out why build proceeds when adding scm.extensions (like on the snippet below), which wasn't required before:

      checkout([
          $class: 'GitSCM',
          branches: scm.branches,
          userRemoteConfigs: [[
            credentialsId: 'foo',
            url          : 'git@github.com:foo/bar.git'
          ]],
          extensions       : scm.extensions + [[
            $class: 'CloneOption',
            noTags: false,
            shallow: false
          ]]
      )]
      

       

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          I'm unable to duplicate the problem. As far as I recall, pull request branch names have always been named "PR-nnn" by GitHub and that name has been assigned to scm.branches in a multibranch pipeline.

          My attempt to duplicate the problem included:

          I ran the job with no extensions defined in the checkout step. The checkout was successful.

          It is possible that git plugin 4.4.1 is choosing the wrong git implementation. That would be visible in the console log with a message about the git "tool" that is being chosen. However, an incorrect git implementation choice should not cause the message "Couldn't find any revision to build. Verify the repository and branch configuration for this job". The most common case for that message is too narrow a git refspec.

          I also confirmed that rolling back to git plugin 4.3.0 does not change the value of scm.branches. It was [PR-10] in both cases.

          Show
          markewaite Mark Waite added a comment - - edited I'm unable to duplicate the problem. As far as I recall, pull request branch names have always been named "PR-nnn" by GitHub and that name has been assigned to scm.branches in a multibranch pipeline. My attempt to duplicate the problem included: Create the JENKINS-63653 branch in my jenkins-bugs GitHub repository Create a pull request that proposes to merge that branch to the master branch Use a job defined with the GitHub branch source provider to detect that pull request and build the branch, reporting the value of scm.branches I ran the job with no extensions defined in the checkout step. The checkout was successful. It is possible that git plugin 4.4.1 is choosing the wrong git implementation. That would be visible in the console log with a message about the git "tool" that is being chosen. However, an incorrect git implementation choice should not cause the message "Couldn't find any revision to build. Verify the repository and branch configuration for this job". The most common case for that message is too narrow a git refspec. I also confirmed that rolling back to git plugin 4.3.0 does not change the value of scm.branches. It was [PR-10] in both cases.
          Hide
          markewaite Mark Waite added a comment -

          Maksym Bordun, any more details on how others can duplicate the problem you're seeing?

          Show
          markewaite Mark Waite added a comment - Maksym Bordun , any more details on how others can duplicate the problem you're seeing?
          Hide
          maksym_bordun Maksym Bordun added a comment -

          Mark Waite sorry, haven't got any time to debug it further and downgrade some plugins, as a temporary fix we use scm.extensions as described earlier. Thank you for taking your time to check it!

          I'll add more info when we'll experiment with plugins versions.

          Show
          maksym_bordun Maksym Bordun added a comment - Mark Waite sorry, haven't got any time to debug it further and downgrade some plugins, as a temporary fix we use scm.extensions as described earlier. Thank you for taking your time to check it! I'll add more info when we'll experiment with plugins versions.
          Hide
          maksym_bordun Maksym Bordun added a comment -

          Should this issue be closed for now?

          Show
          maksym_bordun Maksym Bordun added a comment - Should this issue be closed for now?
          Hide
          markewaite Mark Waite added a comment -

          Closing it would be great for me. If you discover more information, you're welcome to reopen it with that new information.

          Show
          markewaite Mark Waite added a comment - Closing it would be great for me. If you discover more information, you're welcome to reopen it with that new information.
          Hide
          maksym_bordun Maksym Bordun added a comment - - edited

          Great, thank you. Closed for now, needs more debugging.

          Show
          maksym_bordun Maksym Bordun added a comment - - edited Great, thank you. Closed for now, needs more debugging.

            People

            • Assignee:
              Unassigned
              Reporter:
              maksym_bordun Maksym Bordun
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: