Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 8. Performing advanced builds
You can set build resources and maximum duration, assign builds to nodes, chain builds, prune builds, and configure build run policies.
8.1. Setting build resources
By default, builds are completed by pods using unbound resources, such as memory and CPU. These resources can be limited.
Procedure
You can limit resource use in two ways:
- Limit resource use by specifying resource limits in the default container limits of a project.
Limit resource use by specifying resource limits as part of the build configuration.
In the following example, each of the
resources,cpu, andmemoryparameters are optional:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: resources: limits: cpu: "100m" 1 memory: "256Mi" 2However, if a quota has been defined for your project, one of the following two items is required:
A
resourcessection set with an explicitrequests:resources: requests: 1 cpu: "100m" memory: "256Mi"- 1
- The
requestsobject 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
LimitRangeobject apply to pods created during the build process.Otherwise, build pod creation will fail, citing a failure to satisfy quota.
8.2. Setting maximum duration
When defining a BuildConfig object, 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 Red Hat OpenShift Service on AWS.
Procedure
To set maximum duration, specify
completionDeadlineSecondsin yourBuildConfig. The following example shows the part of aBuildConfigspecifyingcompletionDeadlineSecondsfield for 30 minutes:spec: completionDeadlineSeconds: 1800
This setting is not supported with the Pipeline Strategy option.
8.3. Assigning builds to specific nodes
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 NodeSelector cannot be matched to a node with those labels, the build still stay in the Pending state indefinitely.
Procedure
Assign builds to run on specific nodes by assigning labels in the
nodeSelectorfield of theBuildConfig, 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=value2andkey2=value2labels.
8.4. Chained builds
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 build that produces the compiled artifact, and a second build that places that artifact in a separate image that runs the artifact.
8.5. Pruning builds
By default, builds that have completed their lifecycle are persisted indefinitely. You can limit the number of previous builds that are retained.
Procedure
Limit the number of previous builds that are retained by supplying a positive integer value for
successfulBuildsHistoryLimitorfailedBuildsHistoryLimitin yourBuildConfig, for example:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: successfulBuildsHistoryLimit: 2 1 failedBuildsHistoryLimit: 2 2
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.
8.6. Build run policy
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, by:
-
Changing
ParalleltoSerialorSerialLatestOnlyand triggering a new build from this configuration causes the new build to wait until all parallel builds complete as the serial build can only run alone. -
Changing
SerialtoSerialLatestOnlyand triggering a new build causes cancellation of all existing builds in queue, except the currently running build and the most recently created build. The newest build runs next.
