[openstack-dev] [infra] [all] project pipeline definition should stay in project-config or project side ?

Ghanshyam Mann gmann at ghanshyammann.com
Wed Feb 14 10:17:19 UTC 2018

On Wed, Feb 14, 2018 at 6:21 PM, Bal√°zs Gibizer
<balazs.gibizer at ericsson.com> wrote:
> On Wed, Feb 14, 2018 at 6:45 AM, Andreas Jaeger <aj at suse.com> wrote:
>> On 2018-02-14 01:28, Ghanshyam Mann wrote:
>>>  On Wed, Feb 14, 2018 at 12:06 AM, Paul Belanger <pabelanger at redhat.com>
>>> wrote:
>>>>  On Tue, Feb 13, 2018 at 11:05:34PM +0900, gmann wrote:
>>>>>  Hi Infra Team,
>>>>>  I have 1 quick question on zuulv3 jobs and their migration part. From
>>>>>  zuulv3 doc [1], it is clear about migrating the job definition and use
>>>>>  those among cross repo pipeline etc.
>>>>>  But I did not find clear recommendation that whether project's
>>>>>  pipeline definition should stay in project-config or we should move
>>>>>  that to project side.
>>>>>  IMO,
>>>>>  'template' part(which has system level jobs) can stay in
>>>>>  project-config. For example below part-
>>>>> https://github.com/openstack-infra/project-config/blob/e2b82623a4ab60261b37a91e311118301927b9b6/zuul.d/projects.yaml#L10507-L10523
>>>>>  Other pipeline definition- 'check', 'gate', 'experimental' etc should
>>>>>  be move to project repo, mainly this list-
>>>>> https://github.com/openstack-infra/project-config/blob/master/zuul.d/projects.yaml#L10524-L11019
>>>>>  If we move those past as mentioned above then, we can have a
>>>>>  consolidated place to control the project pipeline for
>>>>>  'irrelevant-files', specific branch etc
>>>>>  ..1 https://docs.openstack.org/infra/manual/zuulv3.html
>>>>  As it works today, pipeline stanza needs to be in a config project[1]
>>>>  (project-config) repo. So what you are suggestion will not work. This
>>>> was done
>>>>  to allow zuul admins to control which pipelines are setup / configured.
>>>>  I am mostly curious why a project would need to modify a pipeline
>>>> configuration
>>>>  or duplicate it into all projects, over having it central located in
>>>>  project-config.
>>>  pipeline stanza  and configuration stay in project-config. I mean list
>>>  of jobs defined in each pipeline for specific project for example
>>>  here[2]. Now we have list of jobs for each pipeline in 2 places, one
>>>  in project-config [2] and second in project repo[3].
>>>  Issue in having it in 2 places:
>>>  - No single place to check what all jobs project will run with what
>>> conditions
>>>  - If we need to modify the list of jobs in pipeline or change other
>>>  bits like irrelevant-files etc then it has to be done in
>>>  project-config. So no full control by project side.
> For me it is even more than two places as the project templates like
> 'integarted-gate'[4] defines jobs to be executed on a project that includes
> the template in the project-config. Which leads to problems like [5]. This
> shows that tracking down why some job runs on a change is fairly non-trivial
> from a developer perspective. Therefore I support to define which jobs run
> on a given project as close to the project as possible and as small number
> of different places as possible. I even volunteer to help with the moving
> from nova perspective.
>> This should be explained in:
>> https://docs.openstack.org/infra/manual/zuulv3.html#what-to-convert
>> So, the standard templates/jobs - incl. PTI mandated ones - should stay
>> in project-config, you can move everything else in-tree,
> As far as I understand this list allows us to solve [5] by simply moving
> every jobs from 'integrated-gate' to the respective project in tree as the
> jobs in that template are not part of the PTI.

I agree on moving job out of 'integrated-gate''as it cannot define
generic 'irrelevant files' for each project. if it define anything
then it does not allow to override that. All other projects also have
same issue like cinder does not want integrated-gate to run on
cinder/test/* files.

If moving integrated-gate to each project side then, is there any
other use case of defining jobs in 'integrated-gate' ? if no then how
about removing the concept of ''integrated-gate''

We had similar issue for Branch things also -


> [4]
> https://github.com/openstack-infra/openstack-zuul-jobs/blob/df8a8e8ee41c1ceb4da458a8681e39de39eafded/zuul.d/zuul-legacy-project-templates.yaml#L93
> [5] https://review.openstack.org/#/c/538908
> Cheers,
> gibi
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list