I agree with Tyler, however... Jenkins-x addresses the issue of merging something broken by a later commit by not allowing anyone to merge and merging by machine. it uses Tide (part of prow) to do this and groups any prs together in a merge commit and retests them in a single batch before merging (in the happy case or breaking the merge into smaller units to identify the bad pr).
the branchsource plugin has all the info required and it could (if anyone had the time and inclination) be extended to merge like this. then you don't need to rebuild everything all the time, just before a potential merge. On Sat, 9 Feb 2019, 01:11 R. Tyler Croy <[email protected] wrote: > (replies inline) > > On Fri, 08 Feb 2019, Kohsuke Kawaguchi wrote: > > > This excessive rebuilding behaviour also causes lots of ops overhead by > > eating up disk space. > > > The disk space issues we experience are due to unaddressed scalability > tickets > in Jenkins Pipeline, we would be seeing them regardless. > > > > > > I think we need to change the current behaviour of ci.jenkins.io. > > > I have been opposed to the change, but I don't consider my voice the final > say > here. > > My objection is that I fundamentally do not believe the green check mark > on a > pull request is accurate unless the pull request is rebuilt and tested > against > the latest HEAD of the target branch, even in cases of fast-forwards. > > > There are 88 pull requests open on Jenkins core right now, and I think it's > absolutely false to characterize anything that hasn't been updated in more > than > three to six months as "valid." > > I believe Daniel and Oleg have done a great job trying to keep things > labeled > and organized, so we can tell that of that 88 we have 27 marked as needing > more > review and 21 marked as works in progress, both going back for 2-3 years. > > > If core alone is causing a denial of service on ci.jenkins.io (it's not), > and > we are unwilling to address the root cause, one easy solution is to add a > specific label for core only, which would be a fixed set of agents, > allowing > other workloads to bypass the bottleneck. > > > If the maintainers of Jenkins core wish to change the settings for > core in ci.jenkins.io, I know at least one of them has the privileges to > do so. > > > Personally, I like the probot suggestion from Oliver a lot more. Stale pull > requests are a boat anchor which drags down an open source community, and > that > is IMHO the underlying problem worth fixing here. > > > > Cheers > -- > GitHub: https://github.com/rtyler > > GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2 > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" 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-dev/20190209011052.GR23906%40grape.brokenco.de > . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" 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-dev/CAPzq3pf0o8Aw8FYj%3DHMBe-PLa8WHKkFesVLayb0Hksmda3JqmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
