[ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

[Eyal Edri]

On Thu, Dec 1, 2016 at 10:10 AM, Barak Korren <bkorren at redhat.com> wrote:

> On 30 November 2016 at 19:12, Vojtech Szocs <vszocs at redhat.com> wrote:
> >
> > So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal
> > mentioned in that thread), we should be able to manually trigger heavy
> > CI (check-merged) job from Gerrit web interface, is that correct?
>
> We could make it a two-step operation where you indicate you want to
> submit, wait for the CI output and then click submit - but why not
> just let the system submit for you?
>
> One road I don't think we should go down is to have 3 CI stages:
> "light" check_patch, "heavy" check_patch and "pre-merge", this looks
> like a design smell to me.
>
> WRT Zuul:
>
> Unless you are using a strict policy like ff-only (which so far seems
> no to scale, because it is essentially a GIL on merging), Zuul is
> essential in order to test the right code in CI (even just for basic
> check_patch testing). So we are working to bring it in (See OVIRT-734
> [1] and OVIRT-882 [2]).
>
> WRT merge gating - Zuul tries to make the process "fire and forget" as
> far as maintainers are concerned - if failures are found, it actually
> tries out different combinations of patches to see if, from a set of
> patches that were asked to be merged, some could be merged even when
> others could not.
>
> > If so, it would be the patch owner's responsibility to submit (merge)
> > only after heavy CI (check-merged) pass?
>
> The question hiding here is wither a maintainer could submit _without_
> passing the "heavy" CI. I'm guessing some maintainers will demand
> that, but I'm hoping in the long run this will not be needed and you
> will know that once submitted, a patch will be eventually merged
> unless it has real issues in it.
>

Another option is not to do it from Gerrit, but via a 'developer' job that
will be able
to run "heavy jobs" on demand, basically we should be able to utilize the
same
flow Zuul will run, only instead of basic sanity, run tier1/2 of testing
and not publish RPMs at the end.

This is more complicated than it sounds ( at least to what we knew about
developer jobs in the past),
So we'll learn more about this as we move forward with the gating project.


>
> > So we could actually write Gerrit plugin using MergeValidationListener
> > that would operate in the following way:
> > ...snip...
>
> Just because something could be written doesn't mean it should - we
> are already stretched too thinly over too much code in the CI system,
> we do not want to maintain any more of it, certainly not in a core
> component like Gerrit.
>
> Then again, this is a prioritization question - it not up to me to decide.
>
> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-734
> [2]: https://ovirt-jira.atlassian.net/browse/OVIRT-882
>
> --
> Barak Korren
> bkorren at redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161201/e9b61e6e/attachment-0001.html>