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

> On 30 November 2016 at 19:12, Vojtech Szocs <vsz...@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
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
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel@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)
Devel mailing list

Reply via email to