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. For more options, visit https://groups.google.com/d/optout.
