add more buildv1 features to the roadmap for vetting wrt buildv2 #41
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -166,9 +166,24 @@ spec: | |
| | Private Builder Image Registry | ⚪️ | | | | ||
| | Runtime Base Image | ⚪️ | | | | ||
| | Binary builds | | | | | ||
| | Image pull policy | | | | | ||
|
There was a problem hiding this comment. I would envision this being something buildv2 does solely by leveraging tekton |
||
| | Inject source via config map | | | | | ||
|
There was a problem hiding this comment. I would envision this being something buildv2 does solely by leveraging tekton |
||
| | Inject source via secret | | | | | ||
|
There was a problem hiding this comment. I would envision this being something buildv2 does solely by leveraging tekton |
||
| | Inject source via image | | | | | ||
|
There was a problem hiding this comment. I would envision this being something buildv2 does solely by leveraging tekton |
||
| | Set image label/ens | | | | | ||
|
There was a problem hiding this comment. I would envision this being something buildv2 does solely by leveraging tekton There was a problem hiding this comment. this is setting labels on the output? what's ens? environment variables? if so env variables would be inputs right? There was a problem hiding this comment. yeah this needs to change to |
||
| | Triggers (SCMs) | | | | | ||
|
There was a problem hiding this comment. https://github.com/tektoncd/triggers already provides this, with more features already IMO, than what we have in buildv1 So I would envision this being something buildv2 does solely by leveraging tekton |
||
| | Triggers (imagestream)| | | | | ||
|
There was a problem hiding this comment. I envision devex changes for this @adambkaplan @siamaksade @bparees, updating our existing image change controller and the existing annotation it has for generic k8s object, to include support for both buildv2 and tekton Certainly we can discuss the pros/cons with @sbose78 of them creating their own controller for buildv2 and this, but IMO the former idea would cost substantially less |
||
| | Pruning of builds | | | | | ||
|
There was a problem hiding this comment. this is suppose to be a tekton feature (though if it has landed I have missed it) perhaps an opportunity for either DEVEX or APPSVC to contribute upstream @adambkaplan @siamaksade @bparees @sbose78 |
||
| | Cancelling of builds | | | | | ||
|
There was a problem hiding this comment. believe this is already in tekton .... build v2 would just need to leverage |
||
| | Chaining of builds | | | | | ||
|
There was a problem hiding this comment. doable via tekton today .... just whether buildv2 encapsulates this in the API like buildv1 did There was a problem hiding this comment. buildv1 didn't really encapsulate it. it just allowed input content to come from an existing image, which you've already covered, and for the push of one image to trigger the build of another, which you've arguably already covered also w/ imagestream triggers There was a problem hiding this comment. ah that's right ... thanks for the clarification. I'll remove this from this table, or a subsequent candidates table if we go down that path, and will refrain from opening an issue for discussion, per that last ask from @siamaksade |
||
| | Image Caching | | | | | ||
|
There was a problem hiding this comment. @adambkaplan as discussed previously IMO DEVEX should either facilitate this with the existing stories or have subsequent ones that make sure our solution is consumable via the |
||
| | Max duration / TO | | | | | ||
|
There was a problem hiding this comment. I think tekton already has this ... if not, this should driven upstream by devtools or devexp |
||
| | Parallel vs. serial execution | | | | | ||
|
There was a problem hiding this comment. again, tekton has ... buildv2 leverages via that |
||
| | ImageStreams support | | | | | ||
|
There was a problem hiding this comment. @adambkaplan another tracking story for devex for consulting and/or provide code libs for this ... perhaps stage this later on after buildv2 matures a little |
||
| | Entitlements | | | | | ||
|
There was a problem hiding this comment. @adambkaplan IMO same story as image cache ... the current CSI plugin choice for mutating annotated pods should work for buildv2 like buildv1 .... then it is a question of any OCM or openshift/builder image changes for buildv1 being pulled into the buildv2 controller |
||
| | Global Proxy support | | | | | ||
|
There was a problem hiding this comment. @adambkaplan another story for us ... either something like |
||
| | Mirror support | | | | | ||
|
There was a problem hiding this comment. same basic notions as with global proxy @adambkaplan |
||
| | new-app/build & odo ? | | | | | ||
|
There was a problem hiding this comment. this is an interesting one (and I still have a question mark here) .... perhaps first a broad discussion with @sbose78 , @adambkaplan, @bparees, @siamaksade, and myself just the assess the current landscape |
||
|
|
||
| [corev1container]: https://github.com/kubernetes/api/blob/v0.17.3/core/v1/types.go#L2106 | ||
| [pipelinesoperator]: https://www.openshift.com/learn/topics/pipelines | ||
|
|
||
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.
I think there are some valuable lessons learned, especially in light of recent build v1 customer activity, as devex has discussed internally along with @bparees, that would should engage with @sbose78 's team on when they are ready to start on this.
Not sure if there is common library logic from buildv1 to share, especially since buildv2 may want to go down a different path than the tar to the build container path buildv1 employs today.
@adambkaplan - initial reaction, this feels like consulting work on our end vs. R&D and/or provided code on our end, but at least warrants discussion on our end