Advanced Build Operations

    You can also limit resource use by specifying resource limits as part of the build configuration. In the following example, each of the , cpu, and memory parameters are optional:

    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:

      1. resources:
      2.   requests: (1)
      3.     cpu: "100m"
      4.     memory: "256Mi"
      1The requests object contains the list of resources that correspond to the list of resources in the quota.

    • A 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 OKD.

    The following example shows the part of a BuildConfig specifying completionDeadlineSeconds field for 30 minutes:

    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.

    1. apiVersion: "v1"
    2. kind: "BuildConfig"
    3. metadata:
    4.   name: "sample-build"
    6.     key1: value1
    7.     key2: value2

    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.

    See Configuring Global Build Defaults and Overrides for more information.

    If the specified NodeSelector cannot be matched to a node with those labels, the build still stay in the Pending state indefinitely.

    For compiled languages (Go, C, C++, Java, etc.), 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. In the following example, a build is combined with a Docker build to compile an artifact that is then placed in a separate runtime image.

    Although this example chains a Source-to-Image build and a Docker build, the first build can use any strategy that will produce an image containing the desired artifacts, and the second build can use any strategy that can consume input content from an image.

    The second build uses with a path to the WAR file inside the output image from the first build. An inline Dockerfile copies that WAR file into a runtime image.

    1. apiVersion: v1
    2. kind: BuildConfig
    3. metadata:
    4.   name: image-build
    5. spec:
    6.   output:
    7.     to:
    8.       kind: ImageStreamTag
    9.       name: image-build:latest
    10.   source:
    11.     type: Dockerfile
    12.     dockerfile: |-
    13.       FROM jee-runtime:latest
    14.       COPY ROOT.war /deployments/ROOT.war
    15.     - from: (1)
    16.         kind: ImageStreamTag
    17.         name: artifact-image:latest
    18.       paths: (2)
    19.       - sourcePath: /wildfly/standalone/deployments/ROOT.war
    20.         destinationDir: "."
    21.   strategy:
    22.     dockerStrategy:
    23.       from: (3)
    24.         kind: ImageStreamTag
    25.         name: jee-runtime:latest
    26.     type: Docker
    27.   triggers:
    28.   - imageChange: {}
    29.     type: ImageChange

    The result of this setup is that the output image of the second build does not need to contain any of the build tools that are needed to create the WAR file. Also, because the second build contains an image change trigger, whenever the first build is run and produces a new image with the binary artifact, the second build is automatically triggered to produce a runtime image that contains that artifact. Therefore, both builds behave as a single build with two stages.

    By default, builds that have completed their lifecycle are persisted indefinitely. You can limit the number of previous builds that are retained by supplying a positive integer value for successfulBuildsHistoryLimit or failedBuildsHistoryLimit as shown in the following sample build configuration.

    1successfulBuildsHistoryLimit will retain up to two builds with a status of completed.
    2failedBuildsHistoryLimit will retain up to two builds with a status of failed, cancelled, or .

    Build pruning is triggered by the following actions:

    • Updating a build configuration.

    Builds are sorted by their creation timestamp with the oldest builds being pruned first.

    Administrators can manually prune builds using the .