feat(build): Task-based builds

[astefanutti]

Move to a task-based build API. This enables decoupling the build scheduling logic from the actual build logic.

This brings more flexibility in the way build logic gets scheduled and executed. For example, tasks can be scheduled using init-containers, hence removing the requirement of relying on persistent volumes to coordinate inputs and outputs of sequential tasks.

Fixes #1069. It enables to use an emptyDir volume to coordinate the Camel Maven build and the Kaniko image build, instead of relying on the creation of a persistent volume claim.

It disables the execution of the Kaniko cache warmer pod, as it seems unreliable with the current Kaniko version and requires relying on a persistent volume. For information, here is the penalty of disabling the cache for the duration of integration kit builds:

$ kubectl get builds.camel.apache.org 
NAME             PHASE       AGE   STARTED   DURATION         ATTEMPTS
kit-route-rest   Succeeded   15m   15m       1m8s    
kit-simple       Succeeded   10m   10m       1m16s   

without caching:

$ kubectl get builds.camel.apache.org 
NAME             PHASE       AGE   STARTED   DURATION         ATTEMPTS
kit-route-rest   Succeeded   15m   15m       3m42s    
kit-simple       Succeeded   10m   10m       3m47s   

This incidentally cleans-up the build API. It removes the embedded integration platform struct from the build CR.

TODO:

• Define tasks build API
• Create build tasks for kit builds
• Adapt build pod scheduling
• Adapt build routine scheduling
• Create S2I task API (Postponed to a subsequent PR)

Release Note

feat(build): Task-based builds
fix(build): Use EmptyDir volumes for Kaniko builds when caching is disabled 
fix(build): Disable Kaniko cache by default

[nicolaferraro]

Seems much cleaner. Should we have also a S2I take type later?

Some ideas on running multiple containers that share data from latest Kubecon: https://youtu.be/iz9_omZ0ctk?t=446

[astefanutti]

Seems much cleaner. Should we have also a S2I take type later?

I think so yes.

[nicolaferraro]

Impressive work. You've also removed the requirement for PVC!

APIs are nicer and much more extensible.

[nicolaferraro]

Can you check conflicts @astefanutti ?

[astefanutti]

@nicolaferraro Sure, I'm on it.

[astefanutti]

I've pushed d10606f so that an emptyDir volume is always used for the build, and that isolates the persistent volume to the sole use of Kaniko image caching.