Re: [ovirt-devel] Merge gating in Gerrit

Will it also auto-rename the database scripts? Please please! Martin On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri <eedri(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com > >> wrote: >>> >>> Il 20/Nov/2016 17:25, "Nir Soffer" <nsoffer(a)redhat.com&gt; ha scritto: >>> > >>> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David <didi(a)redhat.com > >>> > wrote: >>> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren <bkorren(a)redhat.com&gt; >>> > > 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(a)ovirt.org >>> > http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >> >> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel > > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel