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