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
toSerial
orSerialLatestOnly
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
toSerialLatestOnly
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:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
sample-build-2 Source Git New
sample-build-3 Source Git New
When the sample-build-1 build completes, the sample-build-2 build will run:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Completed 43 seconds ago 34s
sample-build-2 Source Git@1aa381b Running 2 seconds ago 2s
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:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
sample-build-2 Source Git Cancelled
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:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Completed 43 seconds ago 34s
sample-build-2 Source Git Cancelled
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:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
sample-build-2 Source Git@a76d881 Running 15 seconds ago 3s
sample-build-3 Source Git@689d111 Running 17 seconds ago 3s
The completion order is not guaranteed:
NAME TYPE FROM STATUS STARTED DURATION
sample-build-1 Source Git@e79d887 Running 13 seconds ago 13s
sample-build-2 Source Git@a76d881 Running 15 seconds ago 3s
sample-build-3 Source Git@689d111 Completed 17 seconds ago 5s