[Container-tools] [node-devel] Community Node.js Builder Images

[Lance Ball]

On Fri, Mar 17, 2017 at 2:08 PM Ben Parees <bparees at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20170317/f2b487b0/attachment.htm>