On Wed, Feb 14, 2018 at 6:45 AM, Andreas Jaeger <a...@suse.com> wrote:
On 2018-02-14 01:28, Ghanshyam Mann wrote:
On Wed, Feb 14, 2018 at 12:06 AM, Paul Belanger <pabelan...@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.

 'template' part(which has system level jobs) can stay in
 project-config. For example below part-


Other pipeline definition- 'check', 'gate', 'experimental' etc should
 be move to project repo, mainly this list-

 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

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:

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.

[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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to