Build Run Policy

Build Run Policy Overview

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.

Serial Run Policy

Setting the runPolicy field to Serial will cause all new builds created from the Build configuration to be run sequentially. That means there will be only one build running at a time and every new build will wait until the previous build completes. Using this policy will result in consistent and predictable build output. This is the default runPolicy.

Triggering three builds from the sample-build configuration, using the Serial policy will result in:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
  3. sample-build-2 Source Git New
  4. sample-build-3 Source Git New

When the sample-build-1 build completes, the sample-build-2 build will run:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Completed 43 seconds ago 34s
  3. sample-build-2 Source Git@1aa381b Running 2 seconds ago 2s
  4. sample-build-3 Source Git New

SerialLatestOnly Run Policy

Setting the runPolicy field to SerialLatestOnly will cause all new builds created from the Build configuration to be run sequentially, same as using the Serial run policy. The difference is that when a currently running build completes, the next build that will run is the latest build created. In other words, you do not wait for the queued builds to run, as they are skipped. Skipped builds are marked as Cancelled. This policy can be used for fast, iterative development.

Triggering three builds from the sample-build configuration, using the SerialLatestOnly policy will result in:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
  3. sample-build-2 Source Git Cancelled
  4. sample-build-3 Source Git New

The sample-build-2 build will be canceled (skipped) and the next build run after sample-build-1 completes will be the sample-build-3 build:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Completed 43 seconds ago 34s
  3. sample-build-2 Source Git Cancelled
  4. sample-build-3 Source Git@1aa381b Running 2 seconds ago 2s

Parallel Run Policy

Setting the runPolicy field to Parallel causes all new builds created from the Build configuration to be run in parallel. This can produce unpredictable results, as the first created build can complete last, which will replace the pushed container image produced by the last build which completed earlier.

Use the parallel run policy in cases where you do not care about the order in which the builds will complete.

Triggering three builds from the sample-build configuration, using the Parallel policy will result in three simultaneous builds:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
  3. sample-build-2 Source Git@a76d881 Running 15 seconds ago 3s
  4. sample-build-3 Source Git@689d111 Running 17 seconds ago 3s

The completion order is not guaranteed:

  1. NAME TYPE FROM STATUS STARTED DURATION
  2. sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
  3. sample-build-2 Source Git@a76d881 Running 15 seconds ago 3s
  4. sample-build-3 Source Git@689d111 Completed 17 seconds ago 5s