apiVersion: "v1"
kind: "BuildConfig"
metadata:
name: "sample-build"
spec:
resources:
limits:
cpu: "100m" (1)
memory: "256Mi" (2)
The following sections provide instructions for advanced build operations including setting build resources and maximum duration, assigning builds to nodes, chaining builds, build pruning, and build run policies.
By default, builds are completed by pods using unbound resources, such as memory and CPU. These resources can be limited.
Limit resources by specifying resource limits in a project’s default container limits.
Or limit resource use by specifying resource limits as part of the
build configuration. In the following example, each of the resources
,
cpu
, and memory
parameters are optional:
apiVersion: "v1"
kind: "BuildConfig"
metadata:
name: "sample-build"
spec:
resources:
limits:
cpu: "100m" (1)
memory: "256Mi" (2)
1 | cpu is in CPU units: 100m represents 0.1 CPU units (100 * 1e-3). |
2 | memory is in bytes: 256Mi represents 268435456 bytes (256 * 2 ^ 20). |
However, if a quota has been defined for your project, one of the following two items is required:
A resources
section set with an explicit requests
:
resources:
requests: (1)
cpu: "100m"
memory: "256Mi"
1 | The requests object contains the list of resources that correspond to
the list of resources in the quota. |
A limit range defined in your project, where the
defaults from the LimitRange
object apply to pods created during the
build process.
Otherwise, build pod creation will fail, citing a failure to satisfy quota.
When defining a BuildConfig
, you can define its maximum duration by setting
the completionDeadlineSeconds
field. It is specified in seconds and is not
set by default. When not set, there is no maximum duration enforced.
The maximum duration is counted from the time when a build pod gets scheduled in the system, and defines how long it can be active, including the time needed to pull the builder image. After reaching the specified timeout, the build is terminated by Azure Red Hat OpenShift.
To set maximum duration, specify completionDeadlineSeconds
in your
BuildConfig
. The following example shows the part of a BuildConfig
specifying completionDeadlineSeconds
field for 30 minutes:
*
spec: completionDeadlineSeconds: 1800
This setting is not supported with the Pipeline Strategy option. |
Builds can be targeted to run on specific nodes by specifying labels in the
nodeSelector
field of a build configuration. The nodeSelector
value is a set
of key/value pairs that are matched to node
labels when scheduling the build
pod.
The nodeSelector
value can also be controlled by cluster-wide default and
override values. Defaults will only be applied if the build configuration does
not define any key/value pairs for the nodeSelector
and also does not define
an explicitly empty map value of nodeSelector:{}
. Override values will replace
values in the build configuration on a key by key basis.
If the specified |
Assign builds to run on specific nodes by assigning labels in the nodeSelector
field of the BuildConfig
, for example:
apiVersion: "v1"
kind: "BuildConfig"
metadata:
name: "sample-build"
spec:
nodeSelector:(1)
key1: value1
key2: value2
1 | Builds associated with this build configuration will run only on nodes with the key1=value2 and key2=value2 labels. |
For compiled languages (such as Go, C, C++, and Java), including the dependencies necessary for compilation in the application image might increase the size of the image or introduce vulnerabilities that can be exploited.
To avoid these problems, two builds can be chained together: one that produces the compiled artifact, and a second build that places that artifact in a separate image that runs the artifact.
By default, builds that have completed their lifecycle are persisted indefinitely. You can limit the number of previous builds that are retained.
Limit the number of previous builds that are retained by
supplying a positive integer value for successfulBuildsHistoryLimit
or
failedBuildsHistoryLimit
in your BuildConfig
, for example:
apiVersion: "v1"
kind: "BuildConfig"
metadata:
name: "sample-build"
spec:
successfulBuildsHistoryLimit: 2 (1)
failedBuildsHistoryLimit: 2 (2)
1 | successfulBuildsHistoryLimit will retain up to two builds with a status of completed . |
2 | failedBuildsHistoryLimit will retain up to two builds with a status of failed , canceled , or error . |
Trigger build pruning by one of the following actions:
Updating a build configuration.
Waiting for a build to complete its lifecycle.
Builds are sorted by their creation timestamp with the oldest builds being pruned first.
The build run policy describes the order in which the builds created from the
build configuration should run. This can be done by changing the value of the
runPolicy
field in the spec
section of the Build
specification.
It is also possible to change the runPolicy
value for existing build
configurations.
Changing Parallel
to Serial
or SerialLatestOnly
and triggering a
new build from this configuration will cause the new build to wait until all
parallel builds complete as the serial build can only run alone.
Changing Serial
to SerialLatestOnly
and triggering a new build will
cause cancellation of all existing builds in queue, except the currently
running build and the most recently created build. The newest build will
execute next.