On Tue, May 05, 2015 at 05:18:00PM +0200, David Caro wrote: > On 05/05, Dan Kenigsberg wrote: > > On Tue, May 05, 2015 at 10:11:09AM +0200, David Caro wrote: > > > On 05/05, Max Kovgan wrote: > > > > hi, Dan. > > > > makes sense to me to focus on 2 use cases: > > > > - pre-commit hook running everything jenkins is running - locally > > > Maybe pre-push instead, that will leverage a bit the local work > > > > - pros: > > > > - nearly identical checks/tests jenkins would running > > > > - doesn't care about IDE/editor > > > > - cons: > > > > - slower > > > > - can be annoying to commit (locally) broken code for later > > > > squashing > > > > If something is too anoying to be run (such as blocking every patch for > > 3 minute unit tests, when the poor developer only wants to post his > > patch and go home) - developer would find a way to skip it. > > > > > > > > > > - editor/IDE marriage with tests/checks running > > > > - pros: > > > > - dev has full control over what runs in checks/tests > > > > - allows to commit "dirty" commit > > > > - shorter ==> quicker than the quickest jenkins option > > > > - cons: > > > > - depends on IDE/editor support > > > > - less checks/tests => higher risk > > > > +1. It boils down to developer and maintainer prudence. > > I have such a plugin in my ViM for static testing; Ido (and everyone > > else) should have one, too. I'm less sure about auto-running `make > > check` at rundom points in time. > > > > > > > > > > I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev > > > > allows this. > > > > > > > > either allows ease of running tests - in 1st case upon git commit, in > > > > the > > > > latter - via a button/shortcut in the devtool. > > > > I can help with setting up either to an early adopter. > > > > Then give it a week or two to get some feedback later how well it goes. > > > > > > > > Besides, we're also trying to speedup jenkins response all the time > > > > I would not mind to BLOCK merging before jenkins hook has responded - > > assuming that I (as a branch maintainer) can remove the jenkins reviewer > > from gerrit. There could be emenrgencies that cannot wait for the > > response. And of course, as a maintainer, I must be able to override the > > decision of the robot (by removing it from the reviewer list). > > I'm actually working on adding a new flag 'Continuous Integration' that can > only be set by maintainers and the ci bot, and that requires +1 to merge > (where > -1 does not block). > > Does that make sense to you? (that way you can't rebase and merge before ci > runs and -1, it's easier to handle permissions, it's easier to spot on the ui, > is clearer it's purpose and does not overload another flag).
Yes, it does! _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra