[tripleo][ci] Reducing merge time by moving nv job to experimental
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. -- Quique Llorente Openstack TripleO CI
On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora <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 rather we spend the time to land the standalone versions and get them voting again. Thanks, -Alex
-- Quique Llorente
Openstack TripleO CI
On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz <aschultz@redhat.com> wrote:
On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora <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
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 ? On Wed, Dec 19, 2018 at 3:48 PM Alex Schultz <aschultz@redhat.com> wrote:
On Wed, Dec 19, 2018 at 7:44 AM Alex Schultz <aschultz@redhat.com> wrote:
On Wed, Dec 19, 2018 at 7:34 AM Felix Enrique Llorente Pastora <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
On 2018-12-20 08:07:56 +0100 (+0100), Felix Enrique Llorente Pastora wrote: [...]
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 ? [...]
If you're expecting reviewers to approve changes which pass voting jobs without waiting for non-voting job to return results, this begs the question why you're running them on changes at all. -- Jeremy Stanley
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
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@nemebean.com> 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"
On 12/20/18 1:07 AM, Felix Enrique Llorente Pastora wrote: 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
-- Quique Llorente Openstack TripleO CI
participants (4)
-
Alex Schultz
-
Ben Nemec
-
Felix Enrique Llorente Pastora
-
Jeremy Stanley