e74f571085
We parse the project-pipeline definition of a job at the location of the project-pipeline. This includes both 'project' stanzas and 'project-templates' which are parsed in exactly the same way. This normally gives us the behavior we expect in that the job variants defined by the project or project-template appear to be defined in the location of the project or project-template. However, in one case, we want a 'late-binding' rather than 'early-binding' behavior. When it comes to calculating implied branch matchers, we want to use the value that would be derived if there were no project-template, and instead the job were simply defined on the project stanza itself. What is intended to happen is that project-pipeline job variants in a config project should never have implied branch matchers (since config projects don't have more than one branch). However, project- pipeline job variants on in-repo project stazas should get an implied branch matcher for the branch it's defined on. This is how we end up with behavior where the project definition in a project's master branch controls behavior only on the master branch (unless branches are explicitly specified), and the definition in a stable branch controls only the stable branch. That behavior should happen regardless of where a project-template is defined. Currently we are setting an implied branch matcher for job variants in a project template at the location of definition. Instead, set them when the job is actually used in a project. Change-Id: I5c8fbb3e0a2ecfac8bd95795be002e8cd15e61db |
||
|---|---|---|
| .. | ||
| fixtures | ||
| nodepool | ||
| unit | ||
| __init__.py | ||
| base.py | ||
| encrypt_secret.py | ||
| make_playbooks.py | ||
| print_layout.py | ||