On 30 November 2016 at 19:12, Vojtech Szocs <vszocs@redhat.com> wrote:
So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal mentioned in that thread), we should be able to manually trigger heavy CI (check-merged) job from Gerrit web interface, is that correct?
We could make it a two-step operation where you indicate you want to submit, wait for the CI output and then click submit - but why not just let the system submit for you? One road I don't think we should go down is to have 3 CI stages: "light" check_patch, "heavy" check_patch and "pre-merge", this looks like a design smell to me. WRT Zuul: Unless you are using a strict policy like ff-only (which so far seems no to scale, because it is essentially a GIL on merging), Zuul is essential in order to test the right code in CI (even just for basic check_patch testing). So we are working to bring it in (See OVIRT-734 [1] and OVIRT-882 [2]). WRT merge gating - Zuul tries to make the process "fire and forget" as far as maintainers are concerned - if failures are found, it actually tries out different combinations of patches to see if, from a set of patches that were asked to be merged, some could be merged even when others could not.
If so, it would be the patch owner's responsibility to submit (merge) only after heavy CI (check-merged) pass?
The question hiding here is wither a maintainer could submit _without_ passing the "heavy" CI. I'm guessing some maintainers will demand that, but I'm hoping in the long run this will not be needed and you will know that once submitted, a patch will be eventually merged unless it has real issues in it.
So we could actually write Gerrit plugin using MergeValidationListener that would operate in the following way: ...snip...
Just because something could be written doesn't mean it should - we are already stretched too thinly over too much code in the CI system, we do not want to maintain any more of it, certainly not in a core component like Gerrit. Then again, this is a prioritization question - it not up to me to decide. [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-734 [2]: https://ovirt-jira.atlassian.net/browse/OVIRT-882 -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/