On 12/20/18 1:07 AM, Felix Enrique Llorente Pastora wrote:
The problem with
experimental is that it requires folks to know to run them (which generally does not happen for our project).
So we have two options here: - Make experimental pipeline run on reviews directly without the "check-experimental" comment. - Create a new pipeline "draf" pipeline at infra, that runs WIP jobs or problematic jobs without interfering in normal production "check" pipeline.
What do you think ?
I think Alex already answered this: Fix the scenario jobs so they can be voting again. We need that coverage or we'll be perpetually breaking services that are only tested in scenarios. As a result, any queue hacks that we do would only be temporary anyway. There's no good reason to spend a bunch of time on a one-off configuration that will go away in the near future (hopefully ;-).
On Wed, Dec 19, 2018 at 3:48 PM Alex Schultz <aschultz@redhat.com <mailto:aschultz@redhat.com>> wrote:
On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz <aschultz@redhat.com <mailto:aschultz@redhat.com>> wrote: > > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora > <ellorent@redhat.com <mailto:ellorent@redhat.com>> wrote: > > > > Hello, > > > > To reduce merge time, would be nice from a review to go from check pipeline to gate pipeline without waiting for non-voting jobs, one way to do that is changing non-voting jobs at different pipelien like experimental one, so we have their result but don't wait for them to change to gate pipepeline. > > > > The goal should be to get them to voting. The problem with > experimental is that it requires folks to know to run them (which > generally does not happen for our project). We currently have the > scenario jobs as non-voting because of capacity problems but we still > need the coverage so I'm not keen on moving them to non-voting. I'd
err experimental not non-voting.
> rather we spend the time to land the standalone versions and get them > voting again. > > Thanks, > -Alex > > > -- > > Quique Llorente > > > > Openstack TripleO CI
-- Quique Llorente
Openstack TripleO CI