A Build resource, describes the process of assembling a container image that copes with the requirement of an Integration or IntegrationKit.

The result of a build is an IntegrationKit that can and should be reused for multiple Integrations.

type Build struct {
	Spec   BuildSpec    (1)
	Status BuildStatus  (2)

type BuildSpec struct {
	Tasks []Task        (3)
1 The desired state
2 The status of the object at current time
3 The build tasks

the full go definition can be found here

life cycle

Build strategy

You can choose from different build strategies. The build strategy defines how a build should be executed. At the moment the available strategies are:

  • buildStrategy: pod (each build is run in a separate pod, the operator monitors the pod state)

  • buildStrategy: routine (each build is run as a go routine inside the operator pod)

Build queues

IntegrationKits and its base images should be reused for multiple Integrations in order to accomplish an efficient resource management and to optimize build and startup times for Camel K Integrations.

In order to reuse images the operator is going to queue builds in sequential order. This way the operator is able to use efficient image layering for Integrations.

By default, builds are queued sequentially based on their layout (e.g. native, fast-jar) and the build namespace.

To avoid having many builds running in parallel the operator uses a maximum number of running builds setting that limits the amount of builds running.

You can set this limit in the IntegrationPlatform settings.

The default values for this limitation is based on the build strategy.

  • buildStrategy: pod (MaxRunningBuilds=10)

  • buildStrategy: routine (MaxRunningBuilds=3)