Centrally managed templates shared across multiple applications, business units, and teams — containing organisation-approved delivery processes and governance controls.
The end-to-end process for a Global Job Template — creating it, adding jobs and steps, and attaching it to a service — is exactly the same as described throughout this document for the Application-Level Job Template. Both V2 and V3 types are available for Global Job Templates as well, and behave the same way described in Section 4.
The only real difference is where you start and who it’s for:
Application-Level Job Template
— created from within a specific Application, and scoped to that application only.
Global Job Template
— available for any application, service, and environment to use once created.
Everything else — cloning a default template, choosing V2 or V3, adding jobs, adding Normal/Parallel/Conditional steps, and attaching the finished template to a service — works exactly as documented in the earlier sections of this guide.
V2 and V3 are the two types of Application-Level Job Templates available in BuildPiper. Both come pre-loaded as default, system-generated templates, so there is no need to create them from scratch. When creating a new application, you can simply clone either template and use it as a starting point.
V22.1 V2 Template
V2 is built for static jobs. Its UI is static, not rendered dynamically — the workflow is predefined, made up of BuildPiper’s standard job types. The V2 default template is pre-loaded with 8 supported job types:
Build Job
Deploy Job
Promote Job
Rollback Job
API Call Job
Jira Ticket Job
Deploy ConfigMaps Job
Deploy Secrets Job
Values in a V2 template are defined at the template level — every service using the template shares the same set of values.
V32.2 V3 Template
V3 is built for dynamic and custom jobs. Its UI is also rendered dynamically — you can create the template and add any number of jobs to it, with any number of steps inside each job, built around exactly what your workflow needs. Values in a V3 template are configured at the service level — each service using the template can set its own values.
Note: Parallel Step and Conditional Step are not supported in V3 yet. Only Normal Steps can currently be added to a V3 template.
2.3 Job Template Types During Application Onboarding
BuildPiper has native support for three kinds of workloads: K8s-based, VM-based, and Mobile workloads. For each kind of workload, BuildPiper comes packaged with a pre-defined job template, built on the V2 and V3 versions described above:
K8s-based
— a type of V2 template. Used for microservice applications that run on Kubernetes. This is the default job template in BuildPiper.
VM-based
— a type of V3 template. Used for applications that run on virtual machines, including non-microservice applications.
Mobile-based
— used for Mobile CI workflows. Android and iOS both use the same default template.
Regardless of which type an application is onboarded with, the process for creating and configuring a Job Template — described in the rest of this document — works the same way.
Navigate to Application → [App Name] → Job Templates. The listing table shows the following columns:
2Choose the “Create New” template
The modal is titled “Do you want to create a Job Template” and includes:
Clone Source toggle (Yes / No) — “Yes” clones from the system Default Job Template. “No” reveals a dropdown to select any other existing template as the clone source instead.
Template Name
Template Description
Complete the fields and click Save.
3Review the New Template in the Listing
After saving, the new template appears as a row in the Job Templates table:
4Open the Template Editor
Editing a template is done via the ⋮ overflow menu on its row — not by clicking the row or template name directly. Select Edit to open the template editor.
Selecting “+ Add New Step” within a job (e.g. Build Job) opens the Add Step(s) wizard, a two-stage flow: Config Step Type followed by Select Steps. A step is the single unit of work within a job. BuildPiper supports three step types:
ANormal Step
executes sequentially, in the order it appears in the job’s step list. Normal steps run one after another, in the exact order they appear in the job’s step list. Each step waits for the previous one to finish before it starts. Use this for the majority of steps where order matters and each step depends on the one before it (e.g. clone the repo, then build, then scan).
BParallel Step
a group of steps that run together, at the same time, instead of one after another. Use this when steps are independent of each other and don’t need to wait — for example, running two different security scans side by side to save time. The whole group still sits at one point in the overall sequence: everything before the group finishes first, then the group runs, then everything after the group continues.
CConditional Step
a step (or set of steps) that only runs when a condition you define is met — for example, only if a previous step’s result equals “passed”. If the condition isn’t met, the step is skipped. Use this to branch out your workflow based on outcomes, instead of always running every step regardless of what happened earlier.
Set Step Type to “Normal Step” and click Continue.
Stage 2 — Select Steps
An info banner confirms: “The steps will get executed sequentially.” The Select Steps screen presents a two-column picker:
Steps (left) — a searchable, paginated catalogue of available steps, filterable by category. Each entry shows a name, category tag(s), a short description.
Added Steps (right) — steps selected for this addition, also searchable.
Click Submit to confirm. Newly added Normal Steps are appended to the end of the job’s existing step sequence.
Figure 7.2 — Select Steps: Normal Step picker
Step Configuration Panel
When you click a step from the list to select it, it gets added to the job. A form then opens asking for a few details needed to run that step; the exact fields depend on the step. For example, node-owasp asks for details like workspace path, application name, and source key. Enter the values and click Save. The step then appears in the job’s step list.
Figure 7.3 — Step Information / parameter configuration panel
Note: The Parallel Step feature is controlled by a System Settings flag in the Admin Portal. If disabled, the Config Step Type screen displays: “Parallel Step feature is turned off in System Settings. Please contact your administrator to enable it.”
Stage 1 — Config Step Type
Set Step Type to “Parallel Step”. An additional required field appears:
Parallel Step Group Name — names the group that the parallel steps will belong to.
Steps you select here will run in parallel to each other, as part of the group. There’s no fixed cap on how many steps a group can hold — a super admin sets that limit in System Settings, based on what the infrastructure can support running at once.
Adding steps works the same way as with a Normal Step: click a step to add it, fill in its basic configuration, and click Save. Add as many steps as the configured limit allows, then click Submit.
In the step canvas view, the group appears as a single box, labeled with the group name and a purple “P” badge. Steps before and after the group still run one at a time, in order — only the steps inside the group run together, at the same time.
Figure 7.5 — Resulting step tree with a Parallel Step group
Set Step Type to “Conditional Step”. Additional required fields appear:
Conditional Step Name
Condition Variable — a dropdown of available variables (e.g. BUILD_GIT_URL).
Add Conditions Value for “[Variable]” — a tag-style input; type a value (e.g. “passed”) and press Enter to add it as a condition. Multiple condition values can be added.
Figure 7.6 — Config Step Type: Conditional Step (condition variable and value configured)
Stage 2 — Select Steps
The Select Steps screen shows a “Condition Values” tab for each condition value you added (e.g. “passed”) — each tab is marked Configured once you’ve assigned a step to it.
Adding steps works the same way as with a Normal Step: click a step to add it, fill in its basic configuration, and click Save. Assign the step(s) that should run when that condition value is matched, then click Submit.
In the step graph, the conditional step appears as a single box with an orange “C” badge, positioned right after the steps that come before it.
Beyond the two-panel editor, each template also has a read-only, zoomed-out graph view (accessible via Back / template name header, with an Edit button and a ⋮ overflow menu at the template level). This view visually lays out:
All jobs in the template on the left, showing enabled (highlighted) vs. disabled (greyed, crossed-eye icon) state
The selected job’s steps as a connected sequential chain
Parallel Step groups as a single branching node (purple “P” badge) containing their member steps
Conditional Steps as a single node (orange “C” badge) at the point they were inserted
Figure 8.1 — Full template canvas view, showing Jobs (left), Build Job steps, and Parallel/Conditional nodes
Note: The ⋮ menu at the template level, and the individual ⋮ menus on Job rows and Step rows within the editor, expose additional row-level actions (e.g. rename, delete, enable/disable) that were not captured in this documentation pass.
Once your Job Template is ready, the next step is to attach it to a service. This is done through the Service Onboarding flow, which is documented separately; no additional configuration is needed on the template side.
