Off topic I think.., but wasn't there a Gerrit plugin Roy wrote for it? On Nov 21, 2016 13:51, "Martin Sivak" <msi...@redhat.com> wrote:
> Will it also auto-rename the database scripts? Please please! > > Martin > > On Mon, Nov 21, 2016 at 12:40 PM, Eyal Edri <ee...@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" <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 >
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
