On 05/21/2014 05:25 PM, Eyal Edri wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "David Caro" <dcaroest@redhat.com> Cc: "infra" <infra@ovirt.org> Sent: Friday, May 16, 2014 9:48:19 PM Subject: Re: About merging patches without tests
On 05/16/2014 05:38 AM, Sandro Bonazzola wrote:
Il 16/05/2014 10:37, David Caro ha scritto:
On Fri 16 May 2014 09:33:44 AM CEST, Sandro Bonazzola wrote:
Il 15/05/2014 18:46, David Caro ha scritto: > Hi! > > From time to time we have some patches that are merged to maste=
r
> branches > without having been tested mostly because the developer merges be= fore > having any > response from the jenkins system. > > Merging one of those patches makes any following test run on that= branch > to > fail, and creating a lot of noise and trouble around all patches = and > jobs. > > So I wanted to stat a little discussion to bring up ideas on how = to > prevent > that. Some random thoughts: > > * -1 the patch at jenkins job start, and reset to 0 on success or= infra > failure, > and keep -1 if jenkins failure > * Only send a message to the patch with 'jenkins jobs started'
I think that something like "jenkins jobs started, please don't me= rge until they finish" should be enough.
> * Setup zuul as gateway, and make it block the patches if they do= not > pass the tests > > > > Cheers! > > > > _______________________________________________ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >
Usually the flow is reabase -> submit, that is done pretty easily f= rom the ui, and it does not give too much time to check any comments (t= he rebase and submit buttons are on the top, and the comments show at =
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed 21 May 2014 04:28:10 PM CEST, Itamar Heim wrote: the
end). So doing that will not help on that case, as the developer would no= t see the comment before submitting. I think we should block, at leas= t for a couple minutes, so he has to read the comments to be able to submit.
We had that before also, adding a comment when the jobs start, but = we removed it by developers request iirc
Also recently you can just press submit and it automatically rebase = before merging. So maybe yes, just a message isn't enough
its not possible to wait for the job on a simple rebase usually - too=
many collisions possible.
we're mostly talking about jobs that fail to compile, i think in those= cases, it worth to wait for jenkins job to finish.
if the previous patch failed to compile - i agree. if a rebase of a patch that passed previously, waiting for another roun= d of jobs isn't practical if other merge in the meantime. I'd say: - wait for it if last patch is several days old. - make sure to check the email from automation post the merge and rever= t/fix if it broke in a short loop.
Maybe we can retake the initiative of testing 'on demand', meaning,=20 that the high load jobs only run after a maintainer +1 and a verified=20 +1, that added to the extra flag might help ease the load and keep=20 master stable: Devel sends patches/rebase/whatever, verifies +1, then a maintainer=20 reviews +1 -> jenkins job starts and adds the 'tested' flag when=20 finished -> maintainer can submit But e will need some control over the maintainers of each project (we=20 have more or less that already as gerrit groups and permissions). -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTfMclAAoJEEBxx+HSYmnDS04H/RA+Y+oM9pvZYa+KzUHDLv+E ZAZfHzrb4R1XWFI77FQS13vCBN1AHJ+msJhffgXnfRIJSfD/DxOtQ688We5aeSWD GFKr9sc+weqH5WovflDeECeX+o1wYTeiMJbFm9tyAjmfqjU917Pvh26D63+g8gcs JX1Ksvs92ExXpk+Kz9NzUJqrOtFIsfUMEamdlDW2cL8wi0d9vYcoch96bspvvmdz 0qwVDnB8zTl/GcjDkGV2a/SLlFL8WktvY1GTXhfvwsyTcB9sGSZkEF4JrufZsNcr LdtpO4yiKUKmFAF0Nx4UgNv2ildSg7vTRftRatWLQe/UgIC2FYITN1lFcTxz2eE= =K7ee -----END PGP SIGNATURE----- --dwEQhFbDne1LuxvT2FdGb3GL2Q2diT44q--