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
2 files changed