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. Otherwise , 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.
Parameterized commands
We could also parameterize the name of batch or shell script in a template job so that you can have a windows pipeline and a linux pipeline based off the same template.
Parameterized fetch artifact specification
What if you have two (or more) templated pipelines that have different upstream pipelines? Each downstream pipeline would want to specify a different artifact to be fetched from parent. Parameters to the rescue again. Simple define a parameter called my-upstream in each of the templated downstream pipelines. Then use the parameter in the fetch artifact specification inside the template as shown above.
In our final Part 6 of "How do I do CD with Go?", I detail ways to model higher-order workflows with Go
"How do I do CD with Go?" blog series:
- Part 1: Domain model, concepts and abstractions
- Part 2: Pipelines and value streams
- Part 3: Traceability with upstream pipeline labeling
- Part 4: Go environments
-
Part 6: Modeling higher-order workflows with Go
See how Go can help you optimize your CD process.