On Wed, Aug 20, 2014 at 10:04 AM, Nicholas Paufler < nicholas.pauf...@goclio.com> wrote:
> Yes, > > I see the same behavior with 2.2.4. I've done some more testing this > morning to confirm with both 2.2.4 and 2.2.5 and I see the same incorrect > behavior with both. > > Is my fundamental impression of how this is supposed to work correct, > though? > I don't know the design or usage of the github webhook, so I can't comment if that is how it is intended to work. > When a github webook push event comes in, the Jenkins github webhook > implementation should be looking at the "ref" in the json push and trying > to match that to any jobs with a corresponding branch name? If, and only > if, it finds a match, it's supposed to queue that job to build? Any there > shouldn't be any reason that an unrelated branch should ever be queued? > > I'm accustomed to the git repository level hooks which I use from my local bare git repository. With those hooks, when a commit is pushed to the local bare git repository, the hook invokes curl to pass the repository URL to Jenkins. Jenkins then causes any job to poll which has polling enabled and uses that repository and is not configured to ignore. Each of the matching jobs poll for changes. Each job which detects changes as a result of that poll will start. In the case you describe, if there were no changes on a branch, then I would expect a poll to happen, but no build would run, since no changes would be detected. We'll need someone who is familiar with the github webhook to answer your question about github webhook behavior. It appears from your description that the github webhook has a capability to somehow limit the matching of which jobs should poll to only those jobs which are matching a specific branch. That's different (as far as I know) than the typical behavior I've used with hooks configured inside local bare repositories. > With both 2.2.4 and 2.2.5 I see it considering and then poking every > branch. Even when a webhook push for a branch that doesn't have a locally > defined job happens, it's poking and queuing every job associated with that > repo. > > I'll get a bug report in if necessary, I just want to make sure that it is > actually a bug and not my understanding of how it's supposed to work that's > the problem. > > Thanks > > Nicholas > > On Tuesday, August 19, 2014 8:06:19 PM UTC-6, Mark Waite wrote: > >> Do you see the same behavior with git plugin 2.2.4? A change was made in >> git plugin 2.2.5 to fix JENKINS-22009. There is now a bug report which >> suggests that change has unintended side effects (see JENKINS-24322). I >> haven't yet had time to investigate if the fix for JENKINS-22009 introduced >> the unintended side effect reported in JENKINS-24322, or if it was >> something else. I probably won't have time to investigate it until this >> weekend (at the earliest). >> >> You could help with that investigation by comparing the behavior of git >> plugin 2.2.4 and git plugin 2.2.5 in your use case. If the behavior is >> significantly different, submit a bug report which describes those >> differences, along with enough details so that I can duplicate the bug, and >> that will increase the odds of the bug being fixed. It may also provide >> you a short term work around (if 2.2.4 behaves more the way you want). >> >> Thanks, >> Mark Waite >> >> >> On Tue, Aug 19, 2014 at 4:03 PM, Nicholas Paufler <nicholas...@goclio.com >> > wrote: >> >>> We're using Jenkins 1.575 with the GIT client (1.10.1), GIT (2.2.5), and >>> GitHub (1.24) plugins (amongst others) but the issue seems to be related to >>> those in some fashion. >>> >>> Specifically, we're using the Jenkins Build Per Branch script ( >>> http://entagen.github.io/jenkins-build-per-branch/) to create Jenkins >>> jobs for every branch in our github repo. That much works great - jobs are >>> created and deleted as branches get added or removed. Each job has the >>> specific branchname specified within. >>> >>> We then have a Github webook setup pointing at our Jenkins install to >>> notify on pushes. That part is also working - but seemingly too well. Every >>> time we get changes to one branch pushed into github, the webhook seems to >>> be causing Jenkins to queue a build for every job. >>> >>> The Jenkins log shows events like the following for every local job. >>> >>> Aug 19, 2014 9:48:22 PM FINE com.cloudbees.jenkins.GitHubWebHook >>> >>> Considering to poke <jobname-based-on-branchname> >>> >>> Aug 19, 2014 9:48:22 PM INFO com.cloudbees.jenkins.GitHubWebHook >>> processGitHubPayload >>> >>> Poked <jobname-based-on-branchname> >>> >>> We see that for everything, even for branches that haven't seen a commit in >>> months. >>> >>> >>> We do have a single Jenkins master and a number of slaves (using swarm >>> slave). All jobs are configured to clean their workspace after they are >>> done executing. >>> >>> Am I misunderstanding how this is supposed to be working, or is there >>> likely something I have configured incorrectly? >>> >>> Any help would be appreciated - thanks! >>> >>> Nicholas >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to jenkinsci-use...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Thanks! >> Mark Waite >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
