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
On Tue, Feb 13, 2018 at 11:05:34PM +0900, gmann wrote:
As it works today, pipeline stanza needs to be in a config
(project-config) repo. So what you are suggestion will not work.
This was done
to allow zuul admins to control which pipelines are setup /
Hi Infra Team,
I have 1 quick question on zuulv3 jobs and their migration part.
zuulv3 doc , it is clear about migrating the job definition
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
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
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
I am mostly curious why a project would need to modify a pipeline
or duplicate it into all projects, over having it central located
pipeline stanza and configuration stay in project-config. I mean
of jobs defined in each pipeline for specific project for example
here. Now we have list of jobs for each pipeline in 2 places, one
in project-config  and second in project repo.
Issue in having it in 2 places:
- No single place to check what all jobs project will run with what
- 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' defines jobs to be executed on a project that
includes the template in the project-config. Which leads to problems
like . 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
in project-config, you can move everything else in-tree,
As far as I understand this list allows us to solve  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.
OpenStack Development Mailing List (not for usage questions)