: trinath.soman...@freescale.com [mailto:trinath.soman...@freescale.com]
Sent: Saturday, August 23, 2014 9:55 AM
To: Doug Wiegley; James E. Blair
Cc: openstack-infra@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
You mean, the blog post of jaypipes. I too used
egley [mailto:do...@a10networks.com]
Sent: Saturday, August 23, 2014 8:28 AM
To: Somanchi Trinath-B39208; James E. Blair
Cc: openstack-infra@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
I’m sure someone in infra can give you an exact answer, but I install
@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
I’m sure someone in infra can give you an exact answer, but I installed in
July, and it has it:
$ zuul --version
Zuul version: 2.0.0.215.gda3a074
… and I was using blog instructions from a year or two prior, which
iegley [mailto:do...@a10networks.com]
>Sent: Saturday, August 23, 2014 8:13 AM
>To: Somanchi Trinath-B39208; James E. Blair
>Cc: openstack-infra@lists.openstack.org
>Subject: Re: [OpenStack-Infra] [Zuul] Understanding
>dequeue-on-new-patchset
>
>Yes, there’s one built into the zuul pr
: Somanchi Trinath-B39208; James E. Blair
Cc: openstack-infra@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
Yes, there’s one built into the zuul process. You don’t have to run a separate
gearman.
doug
On 8/22/14, 8:29 PM, "trinath.
208
>Cc: openstack-infra@lists.openstack.org
>Subject: Re: [OpenStack-Infra] [Zuul] Understanding
>dequeue-on-new-patchset
>
>"trinath.soman...@freescale.com" writes:
>
>> Hi Jim-
>>
>> As you said,
>>
>> [ Strictly speaking, that will mean th
t.com]
Sent: Friday, August 22, 2014 11:30 PM
To: Somanchi Trinath-B39208
Cc: openstack-infra@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
"trinath.soman...@freescale.com" writes:
> Hi Jim-
>
> As you said,
>
> [ Strictly
"trinath.soman...@freescale.com" writes:
> Hi Jim-
>
> As you said,
>
> [ Strictly speaking, that will mean that every patchset will go through the
> merger and Jenkins.
>But if testing for a patchset is in progress when a new patchset is
> uploaded, the tests will abort. ]
>
>
> Th
air [mailto:cor...@inaugust.com]
Sent: Friday, August 22, 2014 3:41 AM
To: Somanchi Trinath-B39208
Cc: openstack-infra@lists.openstack.org; openst...@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
"trinath.soman...@freescale.com" writes
:41 AM
To: Somanchi Trinath-B39208
Cc: openstack-infra@lists.openstack.org; openst...@lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
"trinath.soman...@freescale.com" writes:
> Hi-
>
> I configured Zuul with paramater, 'deque
On 2014-08-21 16:17:05 -0700 (-0700), James E. Blair wrote:
> Jobs in the Gearman queue are definitely supposed to be canceled; if
> not, that's a bug (and not a known one).
It's not behavior I'd seen since some time last year, and while I
remember it was fairly non-obvious when we spotted it I do
Jeremy Stanley writes:
> On 2014-08-21 15:11:13 -0700 (-0700), James E. Blair wrote:
> [...]
>> Strictly speaking, that will mean that every patchset will go through
>> the merger and Jenkins. But if testing for a patchset is in progress
>> when a new patchset is uploaded, the tests will abort.
On 2014-08-21 15:11:13 -0700 (-0700), James E. Blair wrote:
[...]
> Strictly speaking, that will mean that every patchset will go through
> the merger and Jenkins. But if testing for a patchset is in progress
> when a new patchset is uploaded, the tests will abort.
[...]
One corner case I think w
"trinath.soman...@freescale.com" writes:
> Hi-
>
> I configured Zuul with paramater, 'dequeue-on-new-patchset: true'.
>
> With this, for a change, if multiple patchsets are in queue, only the latest
> must be taken and rest all to be ignored.
>
> But I noticed that every patchset is going to zuu
Hi-
I configured Zuul with paramater, 'dequeue-on-new-patchset: true'.
With this, for a change, if multiple patchsets are in queue, only the latest
must be taken and rest all to be ignored.
But I noticed that every patchset is going to zuul-merger to Geraman and to
Jenkins finally.
Is there a
15 matches
Mail list logo
