-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(build): Task-based builds #1121
Conversation
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 |
I think so yes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Impressive work. You've also removed the requirement for PVC!
APIs are nicer and much more extensible.
Can you check conflicts @astefanutti ? |
@nicolaferraro Sure, I'm on it. |
I've pushed d10606f so that an |
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:
without caching:
This incidentally cleans-up the build API. It removes the embedded integration platform struct from the build CR.
TODO:
Create S2I task API(Postponed to a subsequent PR)Release Note