[ovirt-devel] Merge gating in Gerrit

[Tal Nisan]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161121/0e4f8191/attachment-0001.html>