On Fri, Mar 17, 2017 at 2:08 PM Ben Parees <[email protected]> wrote:
> > yeah, pretty much... so yes, not "free" and there is some non-zero value > in offering an "s2i_sdk" type image. Perhaps the most sensible thing to do > would be to create the lightweight s2i_core image and then layer the > "commonly needed packages" on top of that image to create the s2i_base > image. Then we're not really introducing a new image, we're just > splitting out the existing layers so you can start at the layer you want. > +1 This seems like a great approach. > > https://docs.openshift.org/latest/dev_guide/builds/advanced_build_operations.html#dev-guide-chaining-builds > > > Interesting. If I want to use chained builds, how do I accomplish that? Do > I need to create a build in the UI, then manually edit the BuildConfig? Or > somehow POST a BuildConfig to OpenShift? Is there any easier and more > intuitive way? > > > basically you create your two buildconfigs using whatever mechanism you > want and edit/configure them as needed to setup the chaining. There's no > tooling specifically around "chain these builds together" if that is what > you're asking. > > > > > I'm curious why this is the suggested approach. From my perspective, > extended builds seem much more intuitive, and certainly easier for the end > user. > > > It was done because extended builds > 1) were limited to s2i based flows (with chained builds you can use an s2i > build to produce a war file and a docker build to add that war into a > runtime image) > 2) were a special case of something you could already do in the product > via chained builds and thus were a redundant codepath/feature to maintain > (with more limitations than the existing capability, per (1)). > 3) required learning another technique (creating more s2i scripts to > support the extended flow, possibly creating more s2i images (runtime and > build specific images), etc, whereas chained builds allows you to more > directly use existing content > > So yeah, it's a bit more configuration work, but it's a more flexible > mechanism that more naturally builds on things people are already doing/can > do instead of introducing a whole new path/type of image/etc. > Points on flexibility. No doubt that, as users/developers become more familiar with the system and build larger and more complex applications that flexibility is great. But imo the usability leaves a little to be desired. There's a lot of assumed knowledge in the docs, and while I understand at a high level what you mean here, I still think I'd need to do a good deal of tinkering, reading, research, etc. to get this going. Lance
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
