Mark Waite added a comment - 2015-07-22 14:10 Kanstantsin Shautsou I don't know the details of the scm.poll() implementation enough to tell you why the second poll returns false. There is a (to me) surprising current behavior in the git plugin which might be relevant here. When a job is running that uses the git plugin, if a poll is needed, then that poll starts (as visible from the UI) but blocks waiting for the current running job to complete. I'm not sure if that is due to synchronization or something else, but it is a behavior that I have consistently observed. Do you think that behavior might have some relevance to this bug?

Kanstantsin Shautsou added a comment - 2015-07-22 14:34 Stepan Mazurov Leon Miller-Out Carsten Brandt could you: update to latest git/github plugins open github-plugin sources in IDE run debug and put breakpoints here https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubPushTrigger.java#L69-L72 create new clean repo (how Mark Waite described) then push into two branches and compare. Mark Waite seems i mistaken, remoting thread pool is wrapped in github descriptor.

Stepan Mazurov added a comment - 2015-07-22 18:27 - edited Unfortunately, I do not have ability to run locally with a debugger. I will, however, share as much info as possible. My github hook log when i pushed develop and master at the same time: Using strategy: Default [poll] Last Built Revision: Revision [sha1] (origin/develop) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url git@[github url] # timeout=10 Pruning obsolete local branches Fetching upstream changes from [github url] > git --version # timeout=10 using GIT_SSH to set credentials A Deploy user > git -c core.askpass= true fetch --tags --progress [github url] +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches > git log --full-history --no-abbrev --format=raw -M -m --raw [older sha1]..[sha 1] # timeout=10 Done. Took 3.1 sec Changes found Only develop built. I then switched the trigger from Build when a change is pushed to GitHub to Poll SCM , and it still only built 1 branch. Here are the logs: Using strategy: Default [poll] Last Built Revision: Revision [sha1] (origin/develop) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url [github project] # timeout=10 Pruning obsolete local branches Fetching upstream changes from [github project] > git --version # timeout=10 using GIT_SSH to set credentials A Deploy user > git -c core.askpass= true fetch --tags --progress [github project] +refs/heads/*:refs/remotes/origin/* --prune Polling for changes in Seen branch in repository origin/develop Seen branch in repository origin/master Seen 2 remote branches Done. Took 1.1 sec No changes github-plugin version: 1.11.3 Edit: and 1.12.0 , functionality unchanged git-plugin version: 2.4.0 git-client version: 1.18.0

Stepan Mazurov added a comment - 2015-07-24 17:11 Mark Waite I effectively did same repro steps as you, with 2 changes: 1. I did not have any post-receive hooks set up, simply SCM poll every minute 2. The "origin" repo was on github Does it work correctly for you if you remove post-receive hook and simply poll? Kanstantsin Shautsou is there anything else I could do to help fix this? Its quite a big issue that I would love to resolve. Effectively all git-flow type workflows are affected.

Mark Waite added a comment - 2015-07-27 03:01 It continues to behave as expected for me if I remove the post-receive hook and simply poll. When I push to multiple branches, multiple jobs are triggered by polling. I assume that there must be something inside the git plugin which decides that multiple jobs need to be scheduled on a single poll result.