--H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09, Yaniv Dary wrote:
=20 =20 ----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set.= =2E. if it was +1, it remains +1 and you can merge (assuming you have +2 on CR)= =2E If it was -1 then you need to wait for the CI to finish, and it might set = it to +1. =20 Does that make sense? =20 Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.
Well, that's more or less what's happening today, we did set up the flag propagation on trivial rebase time ago. I'll have to check how to make jenkins ignore those trivial rebases only if they have a +1. So are you sure that having no merge conflict means that the rebase patch works as before? (I imagine for example that you could have two features that together might not work well, even if they do not touch the same code)
=20
=20 ----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 =20 =20 ----- Original Message -----
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we = might end up rebasing forever. =20 For now we will have to, all the code that is going to be merged mu= st be tested as it is going to be merged, that means running the tests= in
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 On 12/09, Oved Ourfali wrote: the last rebase too. =20 In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, = so you will just add the flag, and that will trigger the gate, that ru= ns the tests and merged the patch. =20 It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). =20 I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, th= at should run on each merge. That will improve the feedback times. =20 =20 So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossi= ble to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way... =20
=20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag =20 Hi! =20 e have been having an issue with gerrit patches being merged be= fore jenkins ran any tests on them, to avoid it from happening again= I propose creating a new gerrit flag (Tests) with the following specifics: =20 =20 +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken =20 where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow over= riding the process. =20 That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to overr= ide the value, she just has to set that flag herself. =20 =20 What do you think? =20 =20 -- David Caro =20 Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D =20 Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 =20 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =20 -- David Caro =20 Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D =20 Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 =20
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =20
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =20
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhu3LAAoJEEBxx+HSYmnDdP0H/3RLp7CSIAP9HgffU/hBC/G2 wEZzBNIgaeeZ4wkjaPjN8tijl7iXX+/1f3CsIZNfrCEkl5b+gd9MZYsoczPGuXxX p8VuYM0Z/MgBNrz6b8p72wAGD3NuaK/UDnlbE7hsaYVb72t2SBBpYbFAvi6h/OWf GfteLxFI6NH3EF6j0u08wE2msM4270G6dh9D6h3nvUzyYAoNUaGFpZKlGGuKV9XC tcuH+i+GGyzg6QF8jBVgLDYKLi2ZYMhfKJpzTNXI8gkcAJp6HRgVi3TrIS5xNpp2 +f688J+oH4c+EZgV/DPu93r4f+OzHnhfK0BNjGX4G0HqYx8la4QN+f2GyaPdgKs= =Oqyk -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2--