About merging patches without tests
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aRDxp1t8OJxB8Ou24htvVk9dCuM28RTPW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! =46rom time to time we have some patches that are merged to master branch= es without having been tested mostly because the developer merges before hav= ing 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= =2E So I wanted to stat a little discussion to bring up ideas on how to preve= nt that. Some random thoughts: * -1 the patch at jenkins job start, and reset to 0 on success or infra f= ailure, and keep -1 if jenkins failure * Only send a message to the patch with 'jenkins jobs started' * Setup zuul as gateway, and make it block the patches if they do not pas= s the tests Cheers! --=20 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 --aRDxp1t8OJxB8Ou24htvVk9dCuM28RTPW 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 iQEcBAEBAgAGBQJTdO9RAAoJEEBxx+HSYmnDxTMH/iwCYfpzm+6SybWJ/VmSVxTE tVIMNLnpYLnh483wBcMCrzzLyXnfQK8mqGyh/iBHc6q5TJYjW7NV6ySkABKm8n3z RhLw9fB0267faD/8QGUjjVwLpF7fAYd2ODVlmCwRVgW8BOGK15xiNdjGZJve38GS gyl2SuHje5/GFRbZvyLOTwB4yNOHONqzk/m3XFVs2D354WqdgRxXNJapND/UnQEJ OmL88esg+zli/SDdrc1kKuccd6X/qcor8Jz5iDG4IrGCLPGXKJng0EVv/DG6V1jD /ucsvV3cgkoLlBvphjTyMC3p55/0j5pbVpFF+ebbR3QXpQfwAA4InKugW7KIBi4= =Cyei -----END PGP SIGNATURE----- --aRDxp1t8OJxB8Ou24htvVk9dCuM28RTPW--
Il 15/05/2014 18:46, David Caro ha scritto:
Hi!
From time to time we have some patches that are merged to master branches without having been tested mostly because the developer merges before 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 merge 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
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Il 15/05/2014 18:46, David Caro ha scritto:
Hi!
From time to time we have some patches that are merged to master branc= hes without having been tested mostly because the developer merges before = having any response from the jenkins system.
Merging one of those patches makes any following test run on that bran= ch to fail, and creating a lot of noise and trouble around all patches and j= obs.
So I wanted to stat a little discussion to bring up ideas on how to pr= event that. Some random thoughts:
* -1 the patch at jenkins job start, and reset to 0 on success or infr= a 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 merge u= ntil they finish" should be enough.
* Setup zuul as gateway, and make it block the patches if they do not =
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Pt3RJE6ISgLjv0vd0oS42hnm3rohO2BCD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri 16 May 2014 09:33:44 AM CEST, Sandro Bonazzola wrote: 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 from=20 the ui, and it does not give too much time to check any comments (the=20 rebase and submit buttons are on the top, and the comments show at the=20 end). So doing that will not help on that case, as the developer would not=20 see the comment before submitting. I think we should block, at least=20 for a couple minutes, so he has to read the comments to be able to=20 submit. We had that before also, adding a comment when the jobs start, but we=20 removed it by developers request iirc -- 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 --Pt3RJE6ISgLjv0vd0oS42hnm3rohO2BCD 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 iQEcBAEBAgAGBQJTdc4sAAoJEEBxx+HSYmnDEwoH/jlqzjSjQPHZcsX5vJZlwIuh B+yAIgpWqmsrdWYt7IMQXi4+FFc/4xpsnpqCtyM28gy4f96OFTJ/lXdCBkcyTDeS +55wEB0fuOFUQVFwWbvojKoNWZvWTyeuu9bQDBvk4tJO9RMANZo/pKEqwKWyBS91 dCsuEWoYWfNwES0nFRkTUckIm+4HdGyafgX/nkW3Qih0SirP5xXLKb/CRaZklr82 oyd8vj4CfEhdfuj01OH3Xob/nDcwUKJxTQ2mM4itXdZQCXqiKnGjWxOOLybjtBYW q9LGQvQNDhFHxQa17+8eCxGKa5UpGJ5hIz4SxKbEvsD8x66COT0H2Y3gXJ+tdjY= =ykCW -----END PGP SIGNATURE----- --Pt3RJE6ISgLjv0vd0oS42hnm3rohO2BCD--
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 master branches without having been tested mostly because the developer merges before 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 merge 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 from the ui, and it does not give too much time to check any comments (the rebase and submit buttons are on the top, and the comments show at the end). So doing that will not help on that case, as the developer would not see the comment before submitting. I think we should block, at least 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
-- 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
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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 master branches without having been tested mostly because the developer merges before 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 merge 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 from the ui, and it does not give too much time to check any comments (the rebase and submit buttons are on the top, and the comments show at the end). So doing that will not help on that case, as the developer would not see the comment before submitting. I think we should block, at least 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.
----- 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 master branches without having been tested mostly because the developer merges before 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 merge 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 from the ui, and it does not give too much time to check any comments (the rebase and submit buttons are on the top, and the comments show at the end). So doing that will not help on that case, as the developer would not see the comment before submitting. I think we should block, at least 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.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Sfrrv3Sx8L9iA1gjr7D1aHoINgo23j0Ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed 21 May 2014 04:25:41 PM CEST, Eyal Edri wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "David Caro" <dcaroest@r=
edhat.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 master branches without having been tested mostly because the developer merges bef= ore 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 a= nd jobs.
So I wanted to stat a little discussion to bring up ideas on how t= o 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 mer= ge 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 fr= om the ui, and it does not give too much time to check any comments (th= e rebase and submit buttons are on the top, and the comments show at t= he end). So doing that will not help on that case, as the developer would not=
see the comment before submitting. I think we should block, at least=
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 w= e removed it by developers request iirc
Also recently you can just press submit and it automatically rebase b= efore 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.
Maybe we can try to add a new flag 'jenkins ran' or similar (maybe=20 tested) that is set by jenkins (or a maintainer) and required to merge?
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- 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 --Sfrrv3Sx8L9iA1gjr7D1aHoINgo23j0Ad 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 iQEcBAEBAgAGBQJTfLfTAAoJEEBxx+HSYmnDxrUIAJV5c7sWEAVkkqDGov5xtsf4 u6NJdpda6zQcYUlmM9kWQfhGgMIbS3ogFUJEYjcvvnQSXjhSKBPuq7dYO0h6gxRa t+w4zrpOzZRuXUNEE60HqkbM13599Q5isiVkyfWqdzy9dxSZm3aAQ4V+Bah/RCTh nuR4QioHJj2xviBFHuOmTZIZhVJeJ+ImJwu4C1bklGtmpcyNMDTG303WBm1hfUaH 6AlbubypmZewjdQ59N8dDWtSCzwNtoQbSjd0S1BDdruV5+2UluV7U5sJu8fi++O9 Se9bbJurxLm41LTRh4ooZNJTSDWRSksLMI63Ab1R8oa5vD/ZiBRk9UQSZccZ4eU= =GSx6 -----END PGP SIGNATURE----- --Sfrrv3Sx8L9iA1gjr7D1aHoINgo23j0Ad--
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 master branches without having been tested mostly because the developer merges before 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 merge 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 from the ui, and it does not give too much time to check any comments (the rebase and submit buttons are on the top, and the comments show at the end). So doing that will not help on that case, as the developer would not see the comment before submitting. I think we should block, at least 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 round 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 revert/fix if it broke in a short loop.
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--
On 05/21/2014 06:32 PM, David Caro wrote:
On Wed 21 May 2014 04:28:10 PM CEST, Itamar Heim wrote:
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 master >> branches >> without having been tested mostly because the developer merges before >> 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 merge > 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 from the ui, and it does not give too much time to check any comments (the rebase and submit buttons are on the top, and the comments show at the end). So doing that will not help on that case, as the developer would not see the comment before submitting. I think we should block, at least 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 round 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 revert/fix if it broke in a short loop.
Maybe we can retake the initiative of testing 'on demand', meaning, that the high load jobs only run after a maintainer +1 and a verified +1, that added to the extra flag might help ease the load and keep master stable:
lets wait a bit till we have the extra hardware up and running?
Devel sends patches/rebase/whatever, verifies +1, then a maintainer reviews +1 -> jenkins job starts and adds the 'tested' flag when finished -> maintainer can submit
But e will need some control over the maintainers of each project (we 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
participants (4)
-
David Caro -
Eyal Edri -
Itamar Heim -
Sandro Bonazzola