<p dir="ltr">Off topic I think.., but wasn't there a Gerrit plugin Roy wrote for it? </p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 21, 2016 13:51, "Martin Sivak" <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Will it also auto-rename the database scripts? Please please!<br>
<br>
Martin<br>
<br>
On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br>
> This isn't gating.<br>
> Just trigger to run more heavy lifting CI jobs, the idea is to replace the<br>
> manual submit with automatic system like Zuul.<br>
><br>
><br>
> On Nov 21, 2016 1:32 PM, "Tal Nisan" <<a href="mailto:tnisan@redhat.com">tnisan@redhat.com</a>> wrote:<br>
>><br>
>> Why not use +1 on verified? That way the patch owner can wait till the<br>
>> code review process is over, mark it as verified, wait for CI and then<br>
>> submit.<br>
>> It doesn't really give much added value to the code reviewers whether it's<br>
>> marked as verified or not<br>
>><br>
>> On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br>
>> wrote:<br>
>>><br>
>>> Il 20/Nov/2016 17:25, "Nir Soffer" <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> ha scritto:<br>
>>> ><br>
>>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>>> > wrote:<br>
>>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>><br>
>>> > > wrote:<br>
>>> > >> Hi all,<br>
>>> > >><br>
>>> > >> Perhaps the main purpose of CI, is to prevent braking code from<br>
>>> > >> getting merged into the stable/master branches. Unfortunately our CI<br>
>>> > >> is not there yet, and one of the reasons for that is that we do<br>
>>> > >> large<br>
>>> > >> amount of our CI tests only _after_ the code is merged.<br>
>>> > >><br>
>>> > >> The reason for that is that when balancing through, but time<br>
>>> > >> consuming, tests (e.g. enging build with all permutations) v.s.<br>
>>> > >> faster<br>
>>> > >> but more basic ones (e.g. "findbugs" and single permutation build),<br>
>>> > >> we<br>
>>> > >> typically choose the faster tests to be run per-patch-set and leave<br>
>>> > >> the through testing to only be run post-merge.<br>
>>> > >><br>
>>> > >> We'd like to change that and have the through tests also run before<br>
>>> > >> merge. Ideally we would like to just hook stuff to the "submit"<br>
>>> > >> button, but Gerrit doesn't allow one to do that easily. So instead<br>
>>> > >> we'll need to adopt some kind of flag to indicate we want to submit<br>
>>> > >> and have Jenkins<br>
>>> > >> "click" the submit button on our behalf if tests pass.<br>
>>> > >><br>
>>> > >> I see two options here:<br>
>>> > >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.<br>
>>> ><br>
>>> > This is problematic. For example in vdsm we have 5 maintainers with<br>
>>> > +2, and 4 maintainers with commit right, but only 2 are commenting<br>
>>> > regularly.<br>
>>> ><br>
>>> > >> 2. Add an "approve" flag that maintainers can set to +1 (This is<br>
>>> > >> what OpenStack is doing).<br>
>>> ><br>
>>> > This seems better.<br>
>>> ><br>
>>> > But there is another requirement - maintainer should be able to commit<br>
>>> > even if jenkins fails. Sometimes the CI is broken, or there are flakey<br>
>>> > tests<br>
>>> > breaking the build, and some jobs are failing regularly (check-merged)<br>
>>> > and I don't want to wait for it.<br>
>>><br>
>>> Either disable the jobs or fix them. Having jobs consitently failing and<br>
>>> just ignore them is just a waste of resources.<br>
>>><br>
>>> ><br>
>>> > Today we can override the CI vote and commit, if we keep it as is I<br>
>>> > don't<br>
>>> > see any problem with this change.<br>
>>> ><br>
>>> > Nir<br>
>>> > ______________________________<wbr>_________________<br>
>>> > Devel mailing list<br>
>>> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Devel mailing list<br>
>>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div></div>