Do not add implied branch matchers in project-templates
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
diff --git a/tests/fixtures/config/templated-project/main.yaml b/tests/fixtures/config/templated-project/main.yaml
index e59b396..bb59838 100644
--- a/tests/fixtures/config/templated-project/main.yaml
+++ b/tests/fixtures/config/templated-project/main.yaml
@@ -5,5 +5,6 @@
config-projects:
- common-config
untrusted-projects:
+ - untrusted-config
- org/templated-project
- org/layered-project