As developer, I do not know/care about builder, I only want to select buildpack strategy to kick off my build, so that is simple for me

[ZhuangYuZY]

Now, in build cr, when I select buildpack as build strategy, I still need to input builder image. It is not good for end user, actually, end user do not need to take care of buildpack image, he just want to consume buildpack capabilities.

apiVersion: build.dev/v1alpha1
kind: Build
metadata:
  name: xxx
spec:
  builder:
    image: heroku/buildpacks:18

So suggest to move the builder image to build strategy cr. When administrator install buildpack strategy, we could select one of buildpack builder.

[ZhuangYuZY]

related with https://github.com/redhat-developer/build/issues/140

For me, I think end user does not need to input builder image when using buildpack strategy.

[zhangtbj]

To meet the goal of this requirement and fix the related bug. I suggest we change the default builder image in the code line: https://github.com/redhat-developer/build/blob/master/pkg/controller/buildrun/generate_taskrun.go#L58 to the a new BUILDPACKS_BUILDER_IMAGE variable: heroku/buildpacks:18 first.

Because we DON'T allow end-user to change OTHER build strategies and all others are related to Dockerfile build.

So if the end-user doesn't set builder image, the buildpacks strategy can use the default one and also FIX the bug of https://github.com/redhat-developer/build/issues/140

In future, if we want to have a better design for the builder image for all strategies, we can do that later.

What do you think @sbose78 ?

[sbose78]

How about we hardcode the builder in the BuildStrategy itself - because the builder is kinda everything. If the builder changes the BuildStrategy container steps might change too?

In build V2 terms, it's a new BuildStrategy itself.

[zhangtbj]

Agree for the current stage.

I think it is also hard to ask the end-user to choose which builder image they need to use. We should provide one in BuildStrategy for them.

But I also suggest we keep the builder parameter in Build as optional, that if for some high-level users or we do some advanced build, we can replace the default builder image in BuildStrategy by using the builder image setting in Build.

How about ^^ ?

[zhangtbj]

Agree for the current stage.

I think it is also hard to ask the end-user to choose which builder image they need to use. We should provide one in BuildStrategy for them.

But I also suggest we keep the builder parameter in Build as optional, that if for some high-level users or we do some advanced build, we can replace the default builder image in BuildStrategy by using the builder image setting in Build.

How about ^^ ?

[sbose78]

We haven't modelled well enough how we should be "overriding" values from a Build to the ones in BuildStrategy. That's a nice design effort that should be undertaken with care because there's a fine line between overriding values and completely modifying the strategy itself :D

[sbose78]

However, yes, to begin with, let's make spec.builder optional and set the value of the of the builder image in the BuildStrategy itself for buildpacks.

[qu1queee]

We haven't modelled well enough how we should be "overriding" values from a Build to the ones in BuildStrategy. That's a nice design effort that should be undertaken with care because there's a fine line between overriding values and completely modifying the strategy itself :D

Yes, this is a great point! I think we can discuss this on the next meeting.

[imjasonh]

Stumbled upon this issue looking for the ability to override the builder image for the buildpacks-v3 BuildStrategy -- it currently hard-codes to docker.io/paketobuildpacks/builder:full and there's no way to override it short of changing the BuildStrategy definition.

This sounds like a good use case for build strategy parameterization (#537), where the buildpacks-v3 BuildStrategy has a default builder, but I can override it if I want to.

apiVersion: shipwright.io/v1alpha1
kind: Build
...
spec:
  strategy:
    name: buildpacks-v3
    params:
      builder: quay.io/some/other/builder

I agree in general the BuildStrategy author's configured builder image should be used, but sometimes it can be useful to override it, e.g., to test out other builders, or to canary a new builder image version.

[adambkaplan]

Builder image is something that is really specific to source-to-image. If all buildpack providers use the same steps (which may be true!), then hypothetically this would be useful for them as well.

[imjasonh]

Builder image is something that is really specific to source-to-image. If all buildpack providers use the same steps (which may be true!), then hypothetically this would be useful for them as well.

Yeah, I believe buildpacks builders are specified such that they can be swappable, to provide different detection/build support.

Either way, overloading the builder field (and indeed having one in the first place) will likely just lead to confusion. This is better solved by BuildStrategy parameters, where the s2i strategy can take a builder parameter, and the buildpacks can too if it wants, with different documentation/semantics.

[zhangtbj]

Hi Jason,

At the beginning, we allowed end user to change builder image, but to avoid confusion, we remove that, because we think most of the end user cannot understand the build implementation very well, it is risky to allow end user to choose other unknown builder images.

And the builder parameter in s2i strategy is not the same level as the builder image for buildpacks and kaniko/buildah build strategy. We ALSO cannot change the base builder image in s2i strategy: https://github.com/shipwright-io/build/blob/master/samples/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml#L33

The builder parameter is an internal parameter for the s2i build.

So if we allow end user to modify the buildpacks or kaniko builder image, it is also confusing with the builder parameter in s2i strategy.

So finally, we provide two buildpacks build strategies: https://github.com/shipwright-io/build/tree/master/samples/buildstrategy/buildpacks-v3

• Paketo
• Heroko
• If there is any new certified buildpacks builder, we can add a new one, like Google, but I don't think there will be too much.

As we know, just two two builder images can be used and verified, others are all unknown.