BuildPiper
Pipelines
Concepts & Configuration

Pipeline Constructs #

A BuildPiper pipeline is composed of stages, jobs and steps. This guide walks through pipeline anatomy, configuration sections, supported job types, creation methods, and pipeline types.

On This Page

▸Pipeline Constructs Overview
▸Stage Execution Outcomes
▸Pipeline Configurations
▸Basic Information
▸Pipeline Workflow Builder
▸V2 Pipeline Jobs
▸Pipeline Creation Methods
▸Types of BP Pipelines

1. Pipeline Constructs Overview #

A pipeline’s construction consists of stages, jobs and steps. With BuildPiper, you can organise your pipeline into jobs and stages following the hierarchy below.

LARGEST
Stage

A logical grouping of jobs within a pipeline. Stages define when and how jobs run — for example, tests run only after code compilation.

MID
Job

A series of steps that run sequentially as a unit. Jobs define what to run — for example, code compilation or test runs.

SMALLEST
Step

The smallest unit of work in a BuildPiper Pipeline. Steps are the atomic operations that compose a job.

BP Snapshot: Pipeline construct hierarchy — stages, jobs, and steps.

Stage Execution Outcomes #

Once all jobs in a stage complete, BuildPiper evaluates the stage outcome and either advances or halts the pipeline.

SUCCESS
All jobs succeed

When every job in a stage finishes successfully, the pipeline automatically moves on to the next stage.

FAILURE
Stage fails

When a stage fails, subsequent stages are not executed, the pipeline is marked as failed, and execution stops.

Manage Failure — Recovery Options #

To recover from a failed state, BuildPiper provides a Manage Failure option. Users can choose one of two paths instead of re-running the entire pipeline.

A
Re-Trigger Failed Execution

Re-trigger the failed execution after addressing the underlying issue.

B
Ignore & Continue

Ignore the failed microservice execution and continue the pipeline with services that completed successfully.

Note: This flexibility allows users to avoid re-running the entire pipeline when only specific services encounter failures.

Pipeline Configurations #

In BuildPiper, pipeline configuration is divided into two key sections. Click either card to jump to its details.

01
Basic Information
▸

Core properties and execution behaviour — name, version, retention, triggers, variables.

02
Pipeline Workflow Builder
▸

Visual interface for designing the end-to-end execution flow of the pipeline.

Basic Information #

The Basic Information section defines the core properties and execution behaviour of a pipeline. These settings control how the pipeline is identified, triggered, executed, and managed within BuildPiper.

Configuration	Mandatory?	Description
Pipeline Name	Yes	The unique identifier assigned to the pipeline within the project.
Pipeline Version	Yes	Specifies the version of the pipeline configuration logic. See the Pipeline Versions comparison below.
Retention Count	Yes	The number of historical pipeline execution logs to be retained on the UI.
Pipeline Execution Via	No	Defines the trigger mode — Manual Parameters, Release Package, or Both.
Trigger Method	No	Sets how the pipeline can be triggered. See the Trigger Methods cards below.
Production Hotfixes	No	A toggle to mark if the pipeline is intended for emergency production fixes. Primarily a metadata field for auditing — these details are captured and shipped to Maturity Insights for production deployment hotfixes.
JIRA Ticket Required	No	If enabled, the user must provide a valid JIRA ticket before triggering. This JIRA ticket can be referenced in the pipeline to update details automatically or pull necessary details from JIRA for execution.
Disable Single Click Execution	No	BuildPiper supports triggering all services configured in the pipeline via a single click. Disabled by default as a safety measure — when enabled, allows simultaneous build and deployment of all services. Should be kept disabled to avoid accidental builds and deployments.
Select Tag on Execution	No	Optional tag selection applied at the time of execution.
Pipeline Variables	No	Custom variables that can be referenced across the pipeline’s jobs and steps.

Pipeline Versions #

V2
Standard CI/CD

Ready out of the box CI/CD, auditing and compliance workflow enabling quick pipeline creation.

V3
Dynamic & Custom

A more dynamic way of creating pipelines — enables dynamic jobs and dynamic workflows. Gives more control and freedom to create custom workflows and powerful automation.

Trigger Methods #

MANUAL
Manual Trigger

User must manually click the trigger button to start execution.

SCHEDULE
Scheduled Trigger

Auto-triggers based on a user-provided cron schedule.

WEB HOOKS
Webhook Trigger

Auto-triggered via Git events like commit, merge, pull request, etc.

Pipeline Workflow Builder #

The Pipeline Workflow Builder provides a visual interface for designing and managing the execution flow of a pipeline. Each stage within the builder represents a logical unit of work and can contain one or more jobs that execute in sequence.

If a pipeline is running for more than one service, a job runs for all services in parallel depending upon the availability of executors.

Builder Canvas Capabilities #

Define Execution Flow

Arrange stages and configure dependencies between them to define the end-to-end execution flow.

Configure Stage Settings

Set stage-level settings, approvals, notifications, and execution conditions.

Monitor Execution Progress

Track job status, approvals, and stage outcomes through a visual representation of the pipeline.

Reuse & Standardise

Reuse delivery processes across teams and projects through standardised workflow templates.

Standard Templates: BuildPiper provides a set of standard pipeline workflow patterns that organisations can adopt as-is. These cover build, deployment, approvals, change management, and release governance. Templates can be customised to align with internal processes, compliance requirements, approval chains, deployment gates, ticketing integrations, validation steps, and release controls.

V2 Pipeline Jobs #

BuildPiper pipelines support execution of the following 14 job types, covering CI build, deployment, approvals, integrations, and recovery.

Job Type	Definition
Build	Compiles source code and packages it into a container image (Docker) or artifact.
Deploy	Downloads the artifact from the container registry and deploys it to the specific environment.
Promote	Moves a verified image/artifact from a lower environment (e.g. QA) to a higher one (e.g. Prod). Promotion is governed by a global system setting called Environment Hierarchy for Artifacts Promote, which defines permitted source and target environment mappings — ensuring controlled and compliant promotion across the delivery pipeline.
Android Build	A mobile-centric build process utilising Android-specific SDKs to generate APKs or AABs.
Deploy to Playstore	Automates the submission of Android binaries to the Google Play Store.
API Call	Executes an HTTP request to interact with external services or trigger webhooks.
Deploy ConfigMap	Manages and injects non-sensitive configuration data into the application environment. Enables deployment of ConfigMaps configured at the environment level, automatically deployed to the respective target environment during pipeline execution.
Deploy Secret	Securely handles and deploys sensitive data like credentials, tokens, and SSH keys.
JIRA Ticket	Manages end-to-end JIRA ticketing throughout the delivery lifecycle. Automates ticket creation, updates, status transitions, and comment management based on the pipeline’s execution progress and outcome. See the JIRA System Settings required below.
Rollback	Reverts the application to the previous stable version in case of deployment failure.
Integration Testing	Runs automated tests to verify that the new build functions correctly with other services.
Trigger Pipeline	Initiates a separate downstream pipeline to handle dependencies or modular workflows.
ServiceNow Ticket	Automates the creation or closure of ServiceNow tickets for compliance and auditing.
Delay Job	Introduces a manual or timed pause in the pipeline (e.g. for a “bake time” or soak test).

JIRA System Settings Required #

To effectively use the JIRA Ticket job, the following system settings must be configured.

JIRA Integration

Defines the JIRA configuration, supported JIRA ticket type selection, and JIRA workflow transitions.

JIRA Proxy Support

Configures proxy settings required for JIRA connectivity in restricted network environments.

JIRA Custom Fields

Maps and manages custom JIRA fields required during ticket creation or updates.

JIRA Pattern

Defines the ticket identification or naming pattern used for JIRA issue association within pipeline workflows.

Pipeline Creation Methods #

BuildPiper supports multiple approaches for creating and managing pipelines, allowing teams to choose the method that best aligns with their workflow and automation requirements.

01
Visual Pipeline Workflow Builder

The Pipeline Workflow Builder provides a drag-and-drop interface for creating pipelines visually. Users can add stages and jobs from the available component library, configure their settings, and define execution dependencies through the canvas. This approach is ideal for users who prefer a graphical experience and want to quickly design or modify pipeline workflows.

BP Snapshot: Visual Pipeline Workflow Builder canvas.

02
YAML-Based Pipeline Creation

BuildPiper allows pipelines to be defined using a BuildPiper-specific YAML specification. Users can export an existing pipeline configuration, maintain it in source control, and upload the YAML file to BuildPiper to automatically create or update the pipeline. This approach enables pipeline-as-code practices — version control, peer reviews, and easier migration of pipeline configurations across environments.

BP Snapshot: YAML-based pipeline creation flow.

03
BPCTL — BuildPiper Command Line Utility

BPCTL is BuildPiper’s command-line interface that enables users to create, update, manage, and automate pipeline configurations programmatically. It is particularly useful for bulk operations.

Types of BP Pipelines #

In BuildPiper, pipelines fall into two distinct types based on their scope and purpose.

TYPE 01
Application Pipeline

Scoped to a single application — manages CI/CD for the services that belong to one application’s delivery lifecycle.

TYPE 02
Global Pipeline

Scoped across multiple applications — handles cross-application orchestration, shared automation, and enterprise-wide delivery patterns.

BuildPiper Documentation · Pipeline Constructs

Last updated: May 2026