Open Stack

Ack, let's fix stuff, so merge time is not a painful thing.

On Thu, Dec 20, 2018 at 5:21 PM Ben Nemec <openstack at nemebean.com> wrote:

>
>
> 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 at redhat.com
> > <mailto:aschultz at redhat.com>> wrote:
> >
> >     On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz <aschultz at redhat.com
> >     <mailto:aschultz at redhat.com>> wrote:
> >      >
> >      > On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora
> >      > <ellorent at redhat.com <mailto:ellorent at 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
>


-- 
Quique Llorente

Openstack TripleO CI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181221/4128448f/attachment.html>