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:

Attachments

Activity

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 - 2014-07-19 20:41 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?

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 - 2014-07-21 16:25 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 - 2014-07-22 01:24 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.