Chapter 2. Build strategies


You can use a curated set of build strategies or cluster build strategies on the OpenShift Container Platform cluster. The Builds for Red Hat OpenShift Operator automatically installs these strategies for use. This automated installation of strategies helps you to quickly get started with Builds.

Builds supports the following cluster build strategies:

  • buildah: Supported on all platforms
  • source-to-image: Supported on the linux/amd64 platform
  • buildpacks: Supported on all platforms
  • buildpacks-extender: Supported on all platforms

2.1. Buildah

The buildah cluster build strategy uses a Dockerfile to build a container image and pushes it to the target registry. You must specify the Dockerfile in the spec.paramValues field of the Build CR.

You can share the buildah strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the buildah strategy at cluster level.

You can configure the following parameters for the buildah strategy:

Expand
Table 2.1. Configuration parameters for buildah
NameTypeDescriptionDefault

build-args

array

Key-value pair of the arguments required by the Dockerfile that is used during the build

[]

registries-block

array

List of registries that must be blocked

[]

registries-insecure

array

List of insecure registries with their fully qualified domain name (FQDN)

[]

registries-search

array

List of registries to search short name images

["registry.redhat.io", "quay.io"]

dockerfile

string

Path of the Dockerfile that is used during the build

"Dockerfile"

storage-driver

string

Storage drivers that are used by buildah, such as overlay or vfs

"vfs"

target

string

Sets the target stage to be built

""

Note

For more information, see Configuring build strategies.

2.2. Source-to-image

This build strategy is composed of source-to-image and buildah. You can use this strategy to generate a container file and prepare the application to build with a builder image. You must specify the builder image in the spec.paramValues field of the Build CR.

You can share the source-to-image strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the source-to-image strategy at cluster level.

You can configure the following parameters for the source-to-image strategy:

Expand
Table 2.2. Configuration parameters for source-to-image
NameTypeDescriptionDefault

registries-block

array

List of registries that must be blocked

[]

registries-insecure

array

List of insecure registries with their FQDN

[]

registries-search

array

List of registries to search short name images

["registry.redhat.io", "quay.io"]

builder-image

string

Location of the builder image that is used during the build

NA

storage-driver

string

Storage drivers that are used by source-to-image, such as overlay or vfs

"vfs"

2.3. Buildpacks

The buildpacks cluster build strategy uses Cloud Native Buildpacks (CNB) to build and push a container image from source code, without requiring a Dockerfile. The configuration details are provided through parameters in the Build resource.

The buildpacks-extender cluster build strategy supports the image extension feature of CNB, in addition to all the capabilities offered by the buildpacks strategy. The buildpacks-extender allows you to modify the builder or run image using a Dockerfile. This is useful for installing system dependencies or applying security configurations that standard Buildpacks cannot handle. The Dockerfile is provided by a Buildpack that supports extensions. To use the extender, set the cnb-extender-kind parameter in the Build resource.

Note

The buildpacks cluster build strategy supports Quarkus and Go-based applications, while the buildpacks-extender cluster build strategy supports Node.js and Python-based applications.

You can configure the following parameters for the buildpacks strategy:

Expand
Table 2.3. Configuration parameters for buildpacks
NameTypeDescriptionDefault

cnb-platform-api

string

Supported Platform API Version

"0.12"

cnb-builder-image

string

Builder image containing the buildpacks

""

cnb-lifecycle-image

string

Image to use while executing Lifecycle phases

"buildpacksio/lifecycle:0.20.8"

cnb-log-level

string

Logging levels

"debug"]

run-image

string

Reference to a run image to use

""

cache-image

string

Name of the persistent app cache image

""

source-subpath

string

Subpath within the source input where the source to build is located

""

env-vars

array

Environment variables to set during build-time

[]

platform-dir

string

Name of the platform directory

"empty-dir"

user-id

string

User ID of the builder image user

"1001"

group-id

string

Group ID of the builder image user

"1001"

user-home

string

Absolute path to the user’s home directory

"/tekton/home"

cache-pvc-name

string

Name of the Persistent Volume Claim for cache

"ws-pvc"

cnb-extender-kind

string

The kind of image to extend (build or run) "build"

""

cnb-extended-dir-exporter

string

Directory of extended layers, passed as -extended flag to the exporter

"/layers/extended"

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat