[OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
trinath.somanchi at freescale.com
trinath.somanchi at freescale.com
Fri Aug 22 17:16:46 UTC 2014
Hi-
I'm using Zuul version: 2.0.0.172.
--
Trinath Somanchi - B39208
trinath.somanchi at freescale.com | extn: 4048
-----Original Message-----
From: Somanchi Trinath-B39208
Sent: Friday, August 22, 2014 11:42 AM
To: 'James E. Blair'
Cc: openstack-infra at lists.openstack.org
Subject: RE: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
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. ]
This above is not happening in my case. Though there are latest patchsets in queue, the Build in Jenkins is not aborted.
When I check the Zuul debug log, I get this error http://paste.openstack.org/show/98555/ which was reported when Zuul tried to abort a build with Jenkins.
My Zuul Layout.yaml is here http://paste.openstack.org/show/98556/.
I feel there is something wrong with Gearman and Jenkins linkage for cancelling a job.
Kindly guide me resolve the issue.
--
Trinath Somanchi - B39208
trinath.somanchi at freescale.com | extn: 4048
-----Original Message-----
From: James E. Blair [mailto:corvus at inaugust.com]
Sent: Friday, August 22, 2014 3:41 AM
To: Somanchi Trinath-B39208
Cc: openstack-infra at lists.openstack.org; openstack at lists.openstack.org
Subject: Re: [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
"trinath.somanchi at freescale.com" <trinath.somanchi at 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 zuul-merger to Geraman and to Jenkins finally.
>
> Is there any configuration in Zuul I need to take care of.
>
> Kindly help me in this regard.
If a change is in a pipeline with, say, patchset 1, and then someone uploads patchset 2, the first should be removed from the pipeline and then patchset 2 enqueued.
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.
If that's not what's happening, can you please provide your layout file along with debug level log messages from startup as well as a time when a change was erroneously not dequeued?
Thanks,
Jim
More information about the OpenStack-Infra
mailing list