A new version of this plugin was released today as well, allowing PR to be built from origin branches as well as from forks:
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Branch+Source+Plugin On Tue, Jul 5, 2016 at 3:37 PM, Mark Waite <[email protected]> wrote: > Aren't the two of you largely describing the use model that is being > attempted with the GitHub Organization Folders plugin? > > It seems to create a new job automatically for each branch (whose name > matches the user supplied naming criteria) with a Jenkinsfile in each > repository (whose name matches the user supplied naming criteria). It also > has a PR tab in the mix, which I believe attempts to automatically create a > new job for each pull request. > > Mark Waite > > On Tue, Jul 5, 2016 at 4:29 PM <[email protected]> wrote: > >> Truly they are. >> >> "Every once in a while (it just happened to me right now again when I >> decided to write this post) Jenkins will silently stop building on pushes. >> The jenkins log shows that it's getting the webhooks from github, and that >> it "pokes" my project, but then it doesn't show the "SCM changes detected" >> line. Once I manually trigger a build, it starts working again. >> >> It also has the issue that the builds aren't parameterized when using the >> github plugin. It would be nice if the git sha from a github push was a >> parameter to the build, but instead once the build starts it relies on the >> local cache to decide what the most recent branch is. This makes it >> impossible (from what I've been able to figure out) to add a button to >> retry a build, which is such a basic feature for a CI platform to have." >> >> While rebuilds work OK for me (I think, though I'm always running from >> the tip of a branch, so I can't verify this.) I have to chime in and agree >> that paramterized builds are mos def are not working. Today I was trying to >> diagnose an issue that cropped up recently. I don't know how exactly things >> were working before, but they sure aren't working now. I created a SO post >> detailing my problem here; >> http://stackoverflow.com/questions/38211266/jenkins-github-plugin-triggering-a-parameterized-build. >> It's basically the same issue I think, illustrated with some pretty >> pictures and debugging info. >> >> I agree that having a separate plugin for GitHub and GitHub Pull Requests >> is silly, since Pull Requests are a GitHub® thing. It would be a good thing >> in my opinion to consolidate some functionality into one plugin. The last >> time I tried to work with the GitHub Pull Request Builder plugin it quickly >> became a nightmare. I ended up restoring a backup of the configuration and >> walking away. It should not be so painful to accomplish such an easy task, >> and I can't imagine that it would be worse to consolidate development >> resources on those two plugins (if the authors are willing to do so.) Now >> that I've written a couple of Pipeline scripts and do delivery, not having >> basic, reliable SCM operations is becoming really painful. >> >> I want to close on a positive note by saying that the default, >> out-of-the-box experience I initially had with GitHub / plugin was OK. >> While it was painful, it was ultimately accomplishable without doing >> anything particularly unseemly. Commits were built and I could see their >> status on GH and I was happy. The pipeline stuff is really slick, and I'm >> quite happy with the new features. Keep it up! >> >> >> -Peter >> >> >> On Thursday, June 23, 2016 at 6:15:59 PM UTC-7, Danny Cosson wrote: >>> >>> I've used Jenkins on and off for the past few years on various projects, >>> and have been using it daily at my current job for a couple of months now, >>> after migrating us from Travis (this is my first time on the list). >>> >>> I always seem to run into issues with the Github plugin, and I wanted to >>> see if anyone else has a similar experience. The default behavior that I >>> think every developer today expects is for every push to a Github branch to >>> trigger a build. For teams that use lots of feature branches and ship code >>> many times an hour, this can be dozens or hundreds of new branches a day >>> that get created, need to be tested, and then get deleted. >>> >>> This does not seem to be how the Github plugin was designed to work, and >>> it feels strained under this scenario. The model it uses of receive a push, >>> then query github for any new branches, print out every branch found on >>> github, then compare against the black box of a local cache and hope that >>> it comes up with the right diff and tests the branch that was just pushed, >>> this is convoluted and seems error prone. Every once in a while (it just >>> happened to me right now again when I decided to write this post) Jenkins >>> will silently stop building on pushes. The jenkins log shows that it's >>> getting the webhooks from github, and that it "pokes" my project, but then >>> it doesn't show the "SCM changes detected" line. Once I manually trigger a >>> build, it starts working again. >>> >>> It also has the issue that the builds aren't parameterized when using >>> the github plugin. It would be nice if the git sha from a github push was a >>> parameter to the build, but instead once the build starts it relies on the >>> local cache to decide what the most recent branch is. This makes it >>> impossible (from what I've been able to figure out) to add a button to >>> retry a build, which is such a basic feature for a CI platform to have. >>> >>> It's also somewhat confusing to a new user that there is a separate >>> Github and Github Pull Request plugin. Building on every push vs building >>> on every push to a PR seems like a small tweak to me, but Jenkins uses two >>> different plugins with two different data flows to accomplish these. >>> >>> It really feels like Jenkins needs a new plugin for "Github 2.0" or >>> "Github Push Model" or something. It should listen for Github webhooks and >>> check t he secret token >>> <https://developer.github.com/webhooks/securing/> to authenticate them, >>> then trigger a parameterized build with the branch name as a variable and >>> the sha as the parameter. >>> >>> After seeing all the awesome plans in the pipeline for modernizing >>> Jenkins in various ways with 2.0 (which really look great, I'm excited for >>> the new UI especially). I wanted to see if there are any plans to update >>> the Github plugin for a more modern environment. >>> >>> From the announcements I've seen around Jenkins 2.0, it seems like >>> there's a strong desire on the Jenkins team to modernize Jenkins to stay >>> competitive, and IMO the biggest pain point of setting up Jenkins vs using >>> something like Travis is that in Travis, the behavior I pretty much always >>> want (build immediately on every push to a branch, ability to click to >>> restart a failed build, push status updates to github) is the default, >>> out-of-the-box behavior, and in Jenkins it takes a lot of fiddling to get >>> all the settings just right to get this working (and even then it doesn't >>> work great). >>> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/42667f80-48c2-4726-b767-bedb0afc064d%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-users/42667f80-48c2-4726-b767-bedb0afc064d%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtG%3DRTzNXipLh9C9poXQJ%3DgwtPmUCBcVejCT%3DCmhtDLUqg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtG%3DRTzNXipLh9C9poXQJ%3DgwtPmUCBcVejCT%3DCmhtDLUqg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Patrick Wolf Product Director - Jenkins CloudBees -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAGDV0P92wB%2BXTYM1YDUGcyJM%2BHjbxxmp1df7fSbCUWjMZzb_Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
