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

      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

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

          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?

          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?

          Mark Waite added a comment -

          Fixed in git-client-plugin 1.10.0

          Mark Waite added a comment - Fixed in git-client-plugin 1.10.0

          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.

          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.

          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.

          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.

          Mark Waite added a comment -

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

          Mark Waite added a comment - git-client-plug 1.10.0 has been released with this fix.

          M Chon added a comment -

          Confirmed fixed! Thank you!

          M Chon added a comment - Confirmed fixed! Thank you!

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

              Created:
              Updated:
              Resolved: