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

Git/GitHub Enterprise (GHE) SCM Polling creates builds with "No Changes" when there are two similarly named branches present

    Details

    • Similar Issues:

      Description

      git-client plugin: 1.9.1
      github plugin: 1.8
      git plugin: 2.2.2

      We had a project which was set up to trigger on GHE changes to the "festivus-dev" branch. We noticed that changes being pushed to the "master" branch on GHE was triggering a the "festivus-dev" branch job.

      It turns out that there was a second "jdoe/blah/festivus-dev" branch that was present and it appeared to cause the polling command to think there were always changes present.

      When we removed the "jdoe/blah/festivus-dev" branch from the repo, polling returned to normal. Changes checked into the "master" branch no longer triggered builds in the "festivus-dev" project.

      We also noticed that when the similarly named branch ("jdoe/blah/festivus-dev") was present in the repo, it did not matter what was entered in the branch section of the project. We had a typo in there, and the build was still being triggered.

      Prior to removing the similarly-named branch, we saw this in the jenkins.log:

      INFO: Poked Festivus_master_CI
      Jul 18, 2014 12:04:04 PM com.cloudbees.jenkins.GitHubWebHook processGitHubPayload
      INFO: Poked Festivus_festivus-dev_CI
      Jul 18, 2014 12:04:04 PM com.cloudbees.jenkins.GitHubWebHook processGitHubPayload
      INFO: SCM changes detected in Festivus_festivus-dev_CI. Triggering #1547
      Jul 18, 2014 12:04:05 PM com.cloudbees.jenkins.GitHubPushTrigger$1 run
      INFO: SCM changes detected in Festivus_master_CI. Triggering #317
      Jul 18, 2014 12:04:13 PM hudson.model.Run execute

      And we also saw this in the polling log:

      Started on Jul 18, 2014 12:04:04 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision 652d86ee1fb4715c28902b386d32d623c15c77e9 (origin/festivus-dev)
      > /usr/bin/git ls-remote -h git@github.some.where.com:SITE/Festivus.git festivus-dev
      Done. Took 0.43 sec
      Changes found

      And we also saw this on the command line:

      git ls-remote -h git@github.some.where.com:SITE/Festivus.git festivus-dev
      849c9e7c5d497816427516146d5bd8f778897641 refs/heads/jdoe/blah/festivus-dev
      652d86ee1fb4715c28902b386d32d623c15c77e9 refs/heads/festivus-dev

      After we removed the jdoe/blah/festivus-dev branch,

      INFO: Poked Festivus_master_CI
      Jul 18, 2014 12:37:55 PM com.cloudbees.jenkins.GitHubWebHook processGitHubPayload
      INFO: Poked Festivus_festivus-dev_CI
      Jul 18, 2014 12:37:55 PM com.cloudbees.jenkins.GitHubWebHook processGitHubPayload
      INFO: SCM changes detected in Festivus_master_CI. Triggering #322

        Attachments

          Activity

          mcsf M Chon created issue -
          Hide
          markewaite Mark Waite added a comment -

          The git-client-plugin 1.10.0 release will include a change which allows the job to specify branch names more precisely. So that we don't break compatibility with existing job definitions, the more specific branch name needs to use a different string.

          Plugin versions prior to 1.10.0 typically used "Branch to build" arguments like "origin/master" or "/develop". Those values had all text left of the right-most slash removed, then the remaining text was used to match branch names. That allowed multiple branches to match a single "branch to build", even if that was not the intention of the job definer. It did not allow precise specification of a single branch, especially when namespaces were used. In your example, it caused "jdoe/blah/festivus-dev" and "festivus-dev" to both match.

          That form of "branch to build" is still supported, but now the "Branches to build" also accepts arguments like "refs/heads/origin/master" and "refs/heads/origin//develop". The "refs/heads" format allows precise specification of the branch to build, without breaking backward compatibility.

          In your case, you'd specify the branch to build as "refs/heads/festivus-dev".

          Would you be willing to try a pre-release version of 1.10.0 to confirm it fixes your issue?

          Show
          markewaite Mark Waite added a comment - The git-client-plugin 1.10.0 release will include a change which allows the job to specify branch names more precisely. So that we don't break compatibility with existing job definitions, the more specific branch name needs to use a different string. Plugin versions prior to 1.10.0 typically used "Branch to build" arguments like "origin/master" or " /develop ". Those values had all text left of the right-most slash removed, then the remaining text was used to match branch names. That allowed multiple branches to match a single "branch to build", even if that was not the intention of the job definer. It did not allow precise specification of a single branch, especially when namespaces were used. In your example, it caused "jdoe/blah/festivus-dev" and "festivus-dev" to both match. That form of "branch to build" is still supported, but now the "Branches to build" also accepts arguments like "refs/heads/origin/master" and "refs/heads/origin/ /develop ". The "refs/heads" format allows precise specification of the branch to build, without breaking backward compatibility. In your case, you'd specify the branch to build as "refs/heads/festivus-dev". Would you be willing to try a pre-release version of 1.10.0 to confirm it fixes your issue?
          Hide
          markewaite Mark Waite added a comment -

          Fixed in git-client-plugin 1.10.0

          Show
          markewaite Mark Waite added a comment - Fixed in git-client-plugin 1.10.0
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          mcsf M Chon added a comment -

          Hi, Mark,
          Yes, I can test out the 1.10.0 plugin. However, after reading your explanation, I still do not understand why Jenkins triggered build the festivus-dev branch when changes were checked into master, not either festivus-dev branch. Also, builds were triggered even when there was a typo in the branch name. It seems like the existence of the 2nd festivus-dev branch caused Jenkins to completely ignore the branch specifier and trigger all builds regardless of the branch they were configured with. Even if both "jdoe/blah/festivus-dev" and "festivus-dev" , a change checked into "master" should not have triggered a build.

          Show
          mcsf M Chon added a comment - Hi, Mark, Yes, I can test out the 1.10.0 plugin. However, after reading your explanation, I still do not understand why Jenkins triggered build the festivus-dev branch when changes were checked into master, not either festivus-dev branch. Also, builds were triggered even when there was a typo in the branch name. It seems like the existence of the 2nd festivus-dev branch caused Jenkins to completely ignore the branch specifier and trigger all builds regardless of the branch they were configured with. Even if both "jdoe/blah/festivus-dev" and "festivus-dev" , a change checked into "master" should not have triggered a build.
          Hide
          markewaite Mark Waite added a comment -

          I've uploaded to google drive in hopes you can download it from there. The zip file contains two plugins. Upload the git client plugin first, then the git plugin.

          Show
          markewaite Mark Waite added a comment - I've uploaded to google drive in hopes you can download it from there. The zip file contains two plugins. Upload the git client plugin first, then the git plugin.
          Hide
          markewaite Mark Waite added a comment -

          git-client-plug 1.10.0 has been released with this fix.

          Show
          markewaite Mark Waite added a comment - git-client-plug 1.10.0 has been released with this fix.
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          mcsf M Chon added a comment -

          Confirmed fixed! Thank you!

          Show
          mcsf M Chon added a comment - Confirmed fixed! Thank you!
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 156748 ] JNJira + In-Review [ 207872 ]

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              mcsf M Chon
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: