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. 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