[ovirt-devel] Merge gating in Gerrit

[Eyal Edri]

Off topic I think..,  but wasn't there a Gerrit plugin Roy wrote for it?

On Nov 21, 2016 13:51, "Martin Sivak" <msivak at redhat.com> wrote:

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