[openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?
Kashyap Chamarthy
kchamart at redhat.com
Mon Jul 4 06:22:11 UTC 2016
On Fri, Jul 01, 2016 at 02:35:34PM +0000, Jeremy Stanley wrote:
> On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote:
> > [Snip description of some nice debugging.]
> >
> > > I'd really love it if there was
> > >
> > > 1. the ability to request checking of just specific jobs eg
> > >
> > > "recheck gate-tempest-dsvm-multinode-full"
> >
> > Yes, this would really be desirable. I recall once asking this exact
> > question on #openstack-infra, but can't find Infra team's response to
> > that.
>
> The challenge here is that you want to make sure it can't be used to
> recheck individual jobs until you have them all passing (like
> picking a pin and tumbler lock). The temptation to recheck-spam
> nondeterministically failing changes is already present, but this
> would make it considerably easier still for people to introduce new
> nondeterministic failures in projects. Maybe if it were tied to a
> special pipeline type, and then we set it only for the experimental
> pipeline or something?
If it reduces nondeterministic spam for the CI Infra, and makes us
achieve the task at hand, sure. [/me need to educate himself a
bit more on the Zuul pipeline infrastructure.]
Worth filing this (and your 'idle pipeline' thought below) in the Zuul
tracker here?
https://storyboard.openstack.org/#!/project/679
> > > 2. the ability to request this recheck to run multiple
> > > times in parallel. eg if i just repeat the 'recheck'
> > > command many times on the same patchset # without
> > > waiting for results
> >
> > Yes, this too, would be _very_ useful for all the reasons you described.
> [...]
>
> In the past we've discussed the option of having an "idle pipeline"
> which repeatedly runs specified jobs only when there are unused
> resources available, so that it doesn't significantly cut into our
> resource pool when we're under high demand but still allows to
> automatically collect a large amount of statistical data.
>
> Anyway, hopefully James Blair can weigh in on this, since Zuul is
> basically in a feature freeze for a while to limit the number of
> significant changes we'll need to forward-port into the v3 branch.
> We'd want to discuss these new features in the context of Zuul v3
> instead.
> --
> Jeremy Stanley
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
/kashyap
More information about the OpenStack-dev
mailing list