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" <tni...@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 <sbona...@redhat.com> > wrote: > >> Il 20/Nov/2016 17:25, "Nir Soffer" <nsof...@redhat.com> ha scritto: >> > >> > On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David <d...@redhat.com> >> wrote: >> > > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren <bkor...@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
