<p dir="ltr"></p>
<p dir="ltr">Il 20/Nov/2016 17:25, &quot;Nir Soffer&quot; &lt;<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>&gt; ha scritto:<br>
&gt;<br>
&gt; On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David &lt;<a href="mailto:didi@redhat.com">didi@redhat.com</a>&gt; wrote:<br>
&gt; &gt; On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren &lt;<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>&gt; wrote:<br>
&gt; &gt;&gt; Hi all,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Perhaps the main purpose of CI, is to prevent braking code from<br>
&gt; &gt;&gt; getting merged into the stable/master branches. Unfortunately our CI<br>
&gt; &gt;&gt; is not there yet, and one of the reasons for that is that we do large<br>
&gt; &gt;&gt; amount of our CI tests only _after_ the code is merged.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The reason for that is that when balancing through, but time<br>
&gt; &gt;&gt; consuming, tests (e.g. enging build with all permutations) v.s. faster<br>
&gt; &gt;&gt; but more basic ones (e.g. &quot;findbugs&quot; and single permutation build), we<br>
&gt; &gt;&gt; typically choose the faster tests to be run per-patch-set and leave<br>
&gt; &gt;&gt; the through testing to only be run post-merge.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; We&#39;d like to change that and have the through tests also run before<br>
&gt; &gt;&gt; merge. Ideally we would like to just hook stuff to the &quot;submit&quot;<br>
&gt; &gt;&gt; button, but Gerrit doesn&#39;t allow one to do that easily. So instead<br>
&gt; &gt;&gt; we&#39;ll need to adopt some kind of flag to indicate we want to submit<br>
&gt; &gt;&gt; and have Jenkins<br>
&gt; &gt;&gt; &quot;click&quot; the submit button on our behalf if tests pass.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I see two options here:<br>
&gt; &gt;&gt; 1. Use Code-Review+2 as the indicator to run &quot;heavy&quot; CI and merge.<br>
&gt;<br>
&gt; This is problematic. For example in vdsm we have 5 maintainers with<br>
&gt; +2, and 4 maintainers with commit right, but only 2 are commenting<br>
&gt; regularly.<br>
&gt;<br>
&gt; &gt;&gt; 2. Add an &quot;approve&quot; flag that maintainers can set to +1 (This is<br>
&gt; &gt;&gt;    what OpenStack is doing).<br>
&gt;<br>
&gt; This seems better.<br>
&gt;<br>
&gt; But there is another requirement - maintainer should be able to commit<br>
&gt; even if jenkins fails. Sometimes the CI is broken, or there are flakey tests<br>
&gt; breaking the build, and some jobs are failing regularly (check-merged)<br>
&gt; and I don&#39;t want to wait for it.</p>
<p dir="ltr">Either disable the jobs or fix them. Having jobs consitently failing and just ignore them is just a waste of resources. <br><br></p>
<p dir="ltr">&gt;<br>
&gt; Today we can override the CI vote and commit, if we keep it as is I don&#39;t<br>
&gt; see any problem with this change.<br>
&gt;<br>
&gt; Nir<br>
&gt; _______________________________________________<br>
&gt; Devel mailing list<br>
&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel">http://lists.ovirt.org/mailman/listinfo/devel</a><br></p>