Pipeline templates are useful when you need two pipelines to do the same things except that they build against different repositories or different branches of the same repository. This latter case is common. You might have a short lived branch and a long lived mainline. Using templates here is better than cloning the mainline pipeline because any future change to the template will automatically get reflected in both mainline and branch. On the other hand, you do want to clone if you want to simply start off as same and then diverge. e.g. perhaps your branch pipeline needs an extra stage.
Parameterized artifact names
Pipeline parameters allow for quite an impressive degree of customization. Say the mainline works against oracle-jdk and we create a branch to support open-jdk. We want the artifact names to reflect this. Just define a pipeline parameter called target_jdk in both pipelines with values oracle-jdk and open-jdk respectively.
Then, in the template, at the appropriate job, specify the name of the artifact as: myproduct_#{target-jdk}_$GO_PIPELINE_LABEL
Parameterized job resources
Next, we want to make sure that the branch pipeline only executes on agents where open-jdk is available. We could do this by tagging all jobs in the template with parameterised resources.
There is a flip side of partitioning agents using resources. Now all jobs in all pipelines need to say via resources what kind of agents they should execute on. Othewise , a job without any resources specified is free to execute on an open-jdk agent or an oracle-jdk agent or any other agent. To achieve true ring-fencing, we need to use the environments feature in Go.
