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 <pe...@cyrusbio.com> 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtG%3DRTzNXipLh9C9poXQJ%3DgwtPmUCBcVejCT%3DCmhtDLUqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
