opendev/infra-specs
Code Issues Proposed changes

Zuul v3: correct vagueness in describing job inheritance

Browse Source 
The indication of what the final job content would be in the case
of modifying a template was unclear.   Correct that and expand on
the algorithm actually used for job inheritance.

Change-Id: Id4c459852235b02aa2cea9f8d8aec36337623537
This commit is contained in:
James E. Blair 2016-10-03 15:04:31 -07:00
parent efe671a2f6
commit f09eaa5852
1 changed files with 16 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
specs/zuulv3.rst
View File

@ -337,10 +337,22 @@ non-voting for a given project in a given pipeline::
jobs:
- pypi-upload
Templates are still supported. If a project lists a job that is
defined in a template that is also applied to that project, the
project-local specification of the job will modify that supplied by
the template.
Project templates are still supported, and can modify job parameters
in the same way described above.
Before Zuul executes a job, it finalizes the job content and
parameters by incorporating input from the multiple job definitions
which may apply. The job that will ultimately be run is a job which
inherits from all of the matching job definitions in the order in
which they were encountered in the configuration. This allows for
increasingly specific job definitions. For example, a python unit
test job may be defined globally. A variant of that job (with the
same name) may be specified with an alternate node definition for
"stable" branches. Further, a project-local job specification may
indicate that job should only run when files in the "tests/" directory
are modified. The result is that the job will only run when files in
"tests/" are modified, and, if the change is on a stable branch, the
alternate node definition will be used.
Currently unique job names are used to build shared change queues.
Since job names will no longer be unique, shared queues must be