BuildPiper
CI Setup
User Portal

Configuring the Build #

Once a service is created and an environment has been associated with it, the platform team can add CI build configurations from the BuildPiper UI. This guide details all four CI configuration segments: source code, advanced settings, variables, and hooks.

On This Page

▸Configuring the Build Overview
▸CI Configuration Segments
▸Source Code Details
▸Advanced Settings
▸CI Variables
▸CI Hooks
▸Workflow & Navigation
▸BP Snapshots

Service-Linked CI

Build configuration is tied to a service and its environment, ensuring each environment can have its own CI settings if required.

UI-Driven Setup

All CI configurations are managed through the BuildPiper UI, allowing platform teams to configure builds without manually editing pipeline files.

CI Configuration Segments #

There are four segments of settings for the CI, each covered in its own section below.

01
Source Code Details
▸

Repository, branch, build context and Dockerfile path settings.

02
Advanced Configurations
▸

Specialised settings for cloning, multi-arch builds, shallow cloning and provenance.

03
CI Variables
▸

Build environment variables and image labels for runtime configuration.

04
Hook Configurations
▸

Pre-hooks and post-hooks for custom script execution around builds.

Source Code Details #

These settings tell BuildPiper where to fetch your source code from and how Docker should build the image.

Field Name	Description / Requirement
Git URL*	Select repository from the drop-down.
Branch	Click on the Load Branch button to select the required branch name.
Build Context*	The directory (and its contents) that Docker uses during the build. It is typically the root of your repository or a specific subfolder.
Dockerfile Path*	Relative path to the Dockerfile with reference to the build context.

Build Context Example

docker build -t myapp .

The trailing dot (.) is the build context — the base location where this command runs.

Advanced Settings #

Advanced settings are configurations that are not enabled by default. They are activated for specific use cases and are controlled through BP system settings.

Note: Each advanced setting must be explicitly enabled from System Settings before it appears in the build configuration UI.

Field Name	Description / Requirement
Clone configurations from an external source	A specialised case where the base repository contains external dependencies that also need to be cloned in order to build the service. Examples include Git submodules and similar dependency-based setups.
Select Platform	By default, BuildPiper supports AMD architecture builds. Users can configure other supported architectures such as ARM. Refer: How to Enable Multi-Arch Builds.
Shallow Cloning	Optimises performance by fetching only the latest commits up to a defined depth instead of the full commit history. Reduces both clone time and storage usage. Disabled by default. Refer: How to enable shallow cloning.
Provenance Attestations	Automatically generates and attaches a “build proof” to every container image. The proof contains source provenance and build metadata, verifying that the image is trustworthy and traceable. When enabled, BP appends `--provenance=true` to the Dockerfile build command.

Inspecting Provenance Attestations #

After pushing the image, you can inspect the provenance information without pulling the full image by using the docker buildx imagetools command.

Bash

docker buildx imagetools inspect my-app:latest --format "{{json .Provenance}}"

Example output (SLSA provenance):

JSON Output

{
  "SLSA": {
    "buildType": "https://mobyproject.org/buildkit@v1",
    "invocation": {
      "configSource": { "entryPoint": "Dockerfile" },
      "environment": { "platform": "linux/amd64" }
    },
    "materials": [{
      "digest": { "sha256": "8b1e78743a03dbb2c95171cc58..." },
      "uri": "pkg:docker/nginx@alpine?platform=linux%2Famd64"
    }],
    "metadata": {
      "buildStartedOn":  "2026-05-26T15:29:42.923Z",
      "buildFinishedOn": "2026-05-26T15:29:49.530Z",
      "buildInvocationID": "jay7isrli44btwoo832n10n29",
      "reproducible": false
    }
  }
}

This output is the SLSA provenance attestation embedded by Docker Buildx/BuildKit for the image registry.buildpiper.in/ot-light:15. For more details, refer to the Docker Documentation — SLSA Provenance.

CI Variables #

Configure environment variables and metadata labels that influence build and runtime behaviour.

Field Name	Description / Requirement
Build Env Details	Key–value pairs passed into containers at runtime. Lets you modify application behaviour without changing the underlying image. The same image can run in different environments (production, staging, etc.) just by changing the environment variables.
Build Labels	Custom metadata/labels added to the generated image — informational stickers (version, maintainer, environment, build details) stored inside the image itself.

Build Env Details — Examples #

Defining environment variables in the Dockerfile:

Dockerfile

ENV APP_ENV=production
ENV PORT=8080

Or passing variables at runtime:

Bash

docker run -e APP_ENV=staging -e PORT=3000 myapp

Build Labels — Inspecting #

Fetch the labels embedded in an image:

Bash

docker inspect --format='{{.Config.Labels}}' myimage

Sample output:

JSON Output

{
  "Config": {
    "Labels": {
      "version": "1.0",
      "maintainer": "team@company.com"
    }
  }
}

CI Hooks #

BuildPiper provides the ability to set up custom pre-hooks and post-hooks during the build information stage, enabling the execution of custom steps before and after the creation of the Docker image.

Field Name	Description / Requirement
Pre / Post Hooks	Enable this configuration to execute custom scripts before or after the build process. Hooks can be added via Command, File Upload, or Git source.

Pre-hooks and post-hooks can be added via the three options offered by BuildPiper:

A
Via Command

Run a Command directly inside the build environment.

B
Via File Upload

Upload a script file and enter the command arguments.

C
Via Git

Select the Git URL, branch, file/folder path and enter command arguments.