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).