<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 10:10 AM, Barak Korren <span dir="ltr"><<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 30 November 2016 at 19:12, Vojtech Szocs <<a href="mailto:vszocs@redhat.com">vszocs@redhat.com</a>> wrote:<br>
><br>
> So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal<br>
> mentioned in that thread), we should be able to manually trigger heavy<br>
> CI (check-merged) job from Gerrit web interface, is that correct?<br>
<br>
</span>We could make it a two-step operation where you indicate you want to<br>
submit, wait for the CI output and then click submit - but why not<br>
just let the system submit for you?<br>
<br>
One road I don't think we should go down is to have 3 CI stages:<br>
"light" check_patch, "heavy" check_patch and "pre-merge", this looks<br>
like a design smell to me.<br>
<br>
WRT Zuul:<br>
<br>
Unless you are using a strict policy like ff-only (which so far seems<br>
no to scale, because it is essentially a GIL on merging), Zuul is<br>
essential in order to test the right code in CI (even just for basic<br>
check_patch testing). So we are working to bring it in (See OVIRT-734<br>
[1] and OVIRT-882 [2]).<br>
<br>
WRT merge gating - Zuul tries to make the process "fire and forget" as<br>
far as maintainers are concerned - if failures are found, it actually<br>
tries out different combinations of patches to see if, from a set of<br>
patches that were asked to be merged, some could be merged even when<br>
others could not.<br>
<span class=""><br>
> If so, it would be the patch owner's responsibility to submit (merge)<br>
> only after heavy CI (check-merged) pass?<br>
<br>
</span>The question hiding here is wither a maintainer could submit _without_<br>
passing the "heavy" CI. I'm guessing some maintainers will demand<br>
that, but I'm hoping in the long run this will not be needed and you<br>
will know that once submitted, a patch will be eventually merged<br>
unless it has real issues in it.<br></blockquote><div><br></div><div>Another option is not to do it from Gerrit, but via a 'developer' job that will be able </div><div>to run "heavy jobs" on demand, basically we should be able to utilize the same</div><div>flow Zuul will run, only instead of basic sanity, run tier1/2 of testing and not publish RPMs at the end.</div><div><br></div><div>This is more complicated than it sounds ( at least to what we knew about developer jobs in the past), </div><div>So we'll learn more about this as we move forward with the gating project.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> So we could actually write Gerrit plugin using MergeValidationListener<br>
> that would operate in the following way:<br>
</span>> ...snip...<br>
<br>
Just because something could be written doesn't mean it should - we<br>
are already stretched too thinly over too much code in the CI system,<br>
we do not want to maintain any more of it, certainly not in a core<br>
component like Gerrit.<br>
<br>
Then again, this is a prioritization question - it not up to me to decide.<br>
<br>
[1]: <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-734" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.<wbr>net/browse/OVIRT-734</a><br>
[2]: <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-882" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.<wbr>net/browse/OVIRT-882</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Barak Korren<br>
<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a><br>
RHCE, RHCi, RHV-DevOps Team<br>
<a href="https://ifireball.wordpress.com/" rel="noreferrer" target="_blank">https://ifireball.wordpress.<wbr>com/</a><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHV DevOps<br>EMEA ENG Virtualization R&D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div></div></div>
</div></div>