--Bu8it7iiRSEf40bY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 squa=
shing
=20
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.
=20
>
=20
> > - editor/IDE marriage with tests/checks running
> > - pros:
> > - dev has full control over what runs in checks/tests
> > - allows to commit "dirty" commit
> > - shorter =3D=3D> quicker than the quickest jenkins option
> > - cons:
> > - depends on IDE/editor support
> > - less checks/tests =3D> higher risk
=20
+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.
=20
> >
> > I did both with: intelliJ/PyCharm and vim, almost 100% sure PyDev all=
ows this.
>
=20
> > 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 goe=
s.
>
=20
> > Besides, we're
also trying to speedup jenkins response all the time
=20
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 (w=
here
-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).
=20
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
Web:
www.redhat.com
RHT Global #: 82-62605
--Bu8it7iiRSEf40bY
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVSN8oAAoJEEBxx+HSYmnDo7YH/1uZzyxxNrIndJniR9kFOKci
urqg5LFXLt9BKT9gN1xDnoubV9ssRd3Y17RFxwUeoBHPJ9PCfUg6Da33rIDQjUbh
xVxlD7LDuig318q8vkQ5z6FwV38f/4f60jYZ2re5fkTuECGQqY1OaJ9cH2H+7Qta
X44vfDGR1i/XeK/EoIgQPJti2NN7eGM6FC6Y/8+pchRGM+kY6m3gwnA+DmL/H/ly
qcEzRx5SdQawfWnGHcgCOe2AAtHSPFhMJ6rDqrHW1WBBid2/IbG9mM3NkI59Q/8W
5zDkUSlISUske+C/wHyWGGVAjY4WEw01SVv8EPx0fwDAfxLRRtdPhkiqNxlvGeI=
=d6wh
-----END PGP SIGNATURE-----
--Bu8it7iiRSEf40bY--