Correct logic problem with job trees
When freezing a job tree for a change, we apply each matching job definition in order to create the final, frozen version of the job for the change. We would do this even if no jobs other than the one defined in the project-pipeline job tree matched. This would mean that a job whose global definition had a restriction such as irrelevant-files, skip-if, or branch might be run desipite that restriction if the entry in the project-pipeline job tree for that job did not include a similar restriction. Those entries are meant to modify jobs defined elsewhere (possibly adding restrictions of their own) but are not intended to *broaden* existing jobs, or even fully define them. To correct this, ensure that the change matches not only the entry in the project-pipeline job tree, but also at least one globally defined variant of the job in question. Change-Id: I36585b8cacfe3c20260dc754a6f246842cb0fdc8 Story: 2000804 Task: 3387
This commit is contained in:
parent
fef88ec289
commit
6e85c2b5ae
|
@ -81,6 +81,9 @@
|
|||
- job:
|
||||
name: layered-project-foo-test5
|
||||
|
||||
- job:
|
||||
name: project-test6
|
||||
|
||||
- project:
|
||||
name: org/templated-project
|
||||
templates:
|
||||
|
|
|
@ -1762,6 +1762,11 @@ class Layout(object):
|
|||
if variant not in inherited:
|
||||
frozen_job.inheritFrom(variant)
|
||||
inherited.add(variant)
|
||||
if not inherited:
|
||||
# A change must match at least one defined job variant
|
||||
# (that is to say that it must match more than just
|
||||
# the job that is defined in the tree).
|
||||
continue
|
||||
if job not in inherited:
|
||||
# Only update from the job in the tree if it is
|
||||
# unique, otherwise we might unset an attribute we
|
||||
|
|
Loading…
Reference in New Issue