I can replicate this using /refs/heads/stable where stable is the branch name I want Jenkins to build against. The /refs/heads/ part is included because that's what's suggested in the documentation, but it doesn't seem to work . Something like */master does work though. This used to work until a few weeks ago.

Not sure if this is the same bug (or if it's simply user error) because I'm not that proficient at Git. The fact that it used to work though led me to comment on this.

Jenkins 1.602
Git Client Plugin 1.16.1
Git Plugin 2.3.5

Hi,

i can confirm this issue, Downgrading Plugins should do as workaround.

Downgrade to
Git Client Plugin 1.15.0
Git Plugin 2.3.4

Hi,

To workaround this issue you must downgrade the Git Plugin to 2.3.4. Downgrading Git Client Plugin is not required.

When i look at my polling log, the ls-remote command is missing the branch name, maybe that is causing the issue.

Confirmed, my bad only the Git Plugin ist needed.

I found a better workaround: you must add origin to your branch field in configuration.
Previously i had "feature/jira-0000" and polling didn't work.
Now i have "origin/feature/jira-000" and polling is working fine.

I checked the source code and compareRemoteRevisionWithImpl is adding the remote name to the heads before doing the comparison against the configured branch but the pattern matcher is not checking if the branch is missing the origin (like it does with refs/ ).

Ok, finally i figure out what is happening.

1. compareRemoteRevisionWithImpl adds remote name to each branch got from that remote (GitSCM.java:586)
2. getPattern add */ to the branch name, if it doesn't contain * or /
// if an unqualified branch was given add a "*/" so it will match branches
// from remote repositories as the user probably intended
In our case, our branch name contains /, then */ is not added. (BranchSpec.java:117)
3. remoteName+remoteBranch is compared against our branchName, it doesn't match.

Proposed fix:
update line BranchSpec.java:126 to
builder.append("(refs/heads/|refs/remotes/|remotes/|origin/)?");
with that fix, i think that block from line 116 to 120 will be not longer needed.

I'm working on a branch for this.

Cheers

We use job trigger by post-receive hook and try to retrieve source from "feature/test" branch.
There was same issue with changes. Albert's advise help. origin/feature/test works fine.

JENKINS-28506 has a regression in 2.3.5 that breaks /refs/heads/foo/bar syntax. I believe foo/bar should also work.

Nicolas, this issue should probably be marked resolved. Do you agree?

Albert Parra are you still working on this? If not I can prepare the branch too

Rather than preparing a proposed fix, would you be willing to evaluate the current changes which are on the master branch?

The git plugin and git client plugin are being tested in hopes of releasing new versions before the end of June. If you're willing to assist with the testing, please download and install a pre-release build of the git client plugin and the git plugin. Problems detected in the pre-release should be e-mailed to Mark Waite and Nicolas De Loof.

I wrote some test ideas if you would like suggestions of areas that need testing. The git plugin supports many different use cases and its automated tests only evaluate a very few of those use cases.

i prepared a fix, and used it on my server, but in the current version (1.17.1) the problem is "solved".
"solved" because the feature/xxx branches are working at polling, but now the "remotes/origin/xxx" branches are failing to catch the updates on polling step.
Now i'm using the official release, but i'll send the unit test i wrote for this to Mark.

Can we please have an update on this? It is causing severe issues for the KDE project, as it breaks our commit hook which our current iteration of Jenkins relies upon.

Simply forcing builds to occur when pushes are done is incredibly inefficient, and not particularly possible as it wastes precious system resources. Please correct this as soon as possible.

See https://build.kde.org/

Ben Cooksley did you revert to git plugin 2.3.4 and did that resolve the issue?

Did you try the pre-release builds of the git plugin and git client plugin that are mentioned in the earlier comment?

I believe the problem is resolved in the current development builds of the next release of the git plugin. It would be a great help to have others also confirm that the current pre-release build resolves the issue.

I can confirm the pre-release builds resolve the issue for me as far as I can tell at this stage.
JIRA had automatically folded that comment out of my view for some reason
Is there a timeline for when this will be fully released?

Very soon. I was hoping to release it by the end of June. I missed that date, but have since found a few more useful fixes for inclusion in the plugin. There is one more merge to be evaluated this weekend, then I'll deploy a pre-release copy into production at my work for a day or two. If there are no surprises from that pre-release deployment, then it release shortly after that.

You can read more about the changes that have been evaluated in the git plugin test prioritization document that I have been using to track the work preparing for this release.

Fix included in git plugin 2.4.0 released 18 July 2015

the problem seems to be back with 2.4.1

Nuance: my jenkins with 2.4.1 does detect changes at all

Ferry Huberts I'm sorry to hear it is not working for you. I have a test case job on my Jenkins server with git plugin 2.4.1 and git client plugin 1.19.1 and it definitely responds to the post-receive trigger on the feature/abc branch when I push a commit to that branch. I also confirmed that the job monitoring the master branch on the same repository correctly is not executed when the commit is pushed to feature/abc.

Can you provide more details to duplicate the specific problem you're seeing?

Ah I think I'm on the wrong issue here.
My problem is that 'Recent Changes' doesn't work.
The trigger works properly.
Sorry for the noise, please close the issue

Same problem here. Though git-plugin docs mention fast-remote has an issue if you don't have a master branch which I do it does explain that the old method of checking out to a workspace is a workaround which does work for me.

https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-FastRemotePolling

I'm experiencing similar symptoms to the original post of this issue, leading me to think that the issue is still here in version 3.0.5.

Particularly: Pushing a new branch named `foo/whatever` triggers correctly, but any subsequent pushes to the same branch do not get picked up and triggered.

Branches that don't have slashes in them appear to behave just fine.

Kevin Nelson can you provide more precise details to duplicate your problem? I just confirmed that the Jenkins jobs in my Docker instance correctly respond to the notifyCommit when a commit arrives on a branch whose name contains a "/".

Steps I took while attempting to duplicate the problem:

1. Clone, build, and run the docker instance

     $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-27332
     $ cd JENKINS-27332
     $ git lfs fetch origin origin/lts-with-plugins
     $ git checkout -b lts-with-plugins -t origin/lts-with-plugins
     $ docker build -t jenkins:JENKINS-27332 .
     $ docker run -i --rm --publish 8080:8080 jenkins:JENKINS-27332
   

2. Connect a web browser to that docker instance (http://localhost:8080)
3. Open the "Bugs - Individual Checks"
4. Click "Poll Now" in the "JENKINS-29796-multi-refspec-ignored-on-poll" job
5. Confirm in the workspace that it performed a checkout of "develop/JENKINS-29796"
6. Commit a change to "develop/JENKINS-29796" in a repo which has a notifyCommit post-receive hook pointed at my Jenkins instance
7. Confirm that the job ran when that notifyCommit hook was received

Mark Waite I'm not 100% sure where the issue is, but here is roughly what I have set up:

1. Existing setup running Jenkins 2.32.1, Git Client 2.3.0, Git Plugin 3.0.5, GitHub Plugin 1.26.1, GitHub Branch Source Plugin 2.0.3, and a bunch of other, seemingly unrelated plugins installed (apologies that this isn't a minimal setup to reproduce – I don't have enough existing knowledge of setting up Jenkins for that to be a simple task)
2. Create "New Item" with a GitHub Organization project type
3. Set up the repository sources (private GitHub organization, proper credentials).. Despite what the instructions [here](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) say, there is no checkbox for "Build when a change is pushed to GitHub"
4. After Saving the repository source, the organization scans, and the relevant repository also scans. During the scan, branches with a slash in them are picked up just fine. Everything gets triggered the first time.
5. Create a new branch in the repo with a slash (for example, `feature/testing-slashes`), make a whitespace change somewhere, and push a commit
6. Observe that this very first push does trigger a test properly.
7. Make another whitespace change to the new branch, and commit and push that change
8. The branch update does not trigger a test.

I can see in the "All logs" that the GitHub webhook is arriving to Jenkins correctly for the update push, but I don't see any indication in the logs of what happens after the webhook is received.

Another thing that I've observed is that if I navigate to the specific repository and then click on "Scan Repository", then click on "Events", I can see a "CREATED" event in response to the original push of the `feature/test-branch`, which successfully triggers the build, but there is no indication of the UPDATED event for the second push. When I update another branch that doesn't have a slash in it, I do see an UPDATED event that does successfully trigger a build.

Hopefully this helps some. Let me know if there's any other info that I can provide (and preferably how to collect the info, since I'm still fairly new to Jenkins).

Thanks!

We're seeing this issue as well. We have polling setting "* * * * *" that polls repo each minute and when you push branch initially, it gets picked up in a minute. But further pushes to the branch will usually be picked up in something like 15-20 minutes which drives us crazy.

This mainly happens when no other work is going on in the repo. If some other branches are changing, then chances that your already pushed branch will be picked up faster than 15-20 minutes are much higher.

This looks like a state sharing + timing bug in Git Plugin. And yes, we also have "/" in branch pattern: `origin/pr/*/merge`.