Off topic I think.., but wasn't there a Gerrit plugin Roy wrote for it?
Will it also auto-rename the database scripts? Please please!
Martin
On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri <eedri@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@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@redhat.com>
>> wrote:
>>>
>>> Il 20/Nov/2016 17:25, "Nir Soffer" <nsoffer@redhat.com> ha scritto:
>>> >
>>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David <didi@redhat.com>
>>> > wrote:
>>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren <bkorren@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@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel