Re: [ovirt-devel] Merge gating in Gerrit

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&gt; > 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&gt; >> > 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