Simplify user experience: have kpack define (Cluster)Store, (Cluster)Builder and (Cluster)Stack from a CNB builder

[anthonydahanne]

In the kpack tutorial, the following steps:

3. Create a cluster store configuration
4. Create a cluster stack configuration
5. Create a Builder configuration

seem to add some burden to the usability of kpack ; for example, reference tool pack or other popular integrations such as spring boot maven plugin or waypoint do not require the user to create a store, stack nor a builder to get started with building images.

If kpack had a similar UX as those tools, we would not have to perform the steps 3, 4 and 5 and instead ask the user to directly specify such an Image definition:

apiVersion: kpack.io/v1alpha3
kind: Image
metadata:
  name: my-image-name
  namespace: default
spec:
  build:
    env:
      - name: "BP_NATIVE_IMAGE"
        value: "true"
      - name: "BP_JVM_VERSION"
        value: "17"
  tag: anthonydahanne/my-image-name
  serviceAccountName: tutorial-service-account
  builder:
    name: paketobuildpacks/builder:0.2.316-full
  source:
    git:
      url: https://github.com/anthonydahanne/my-image-name
      revision: 1eef2a9d94845e12b6eff8c4aba9ecc6d8c3e727

The notable difference with the existing kpack.io/v1alpha2:Image is that the builder field is just a string, referencing an existing CNB builder.

I understand that forcing the user into the kpack internals (Store, Stack, Builder) has its advantages for some users wanting to rely on the tool to refresh the stacks and builders automatically, hence triggering rebuilds of image; but on the other hand, have the user specify a versioned builder and have them either refresh manually the CNB builder version themselves, or accept semver strings for their CNB builder

  builder:
    name: paketobuildpacks/builder:~0.2

would achieve, I think, the same purpose - once again not having the user deal with internal kpack resources.

---

If that suggested UX makes sense, I believe it could be implemented via either

• a kp addition; such as:

kp builder create --from-cnb-builder=paketobuildpacks/builder:0.2.316-full that would create under the hood all required internal resources (Builder, Stack and Store, with default values / names) - a little bit similar to pack config default-builder paketobuildpacks/builder:0.2.316-full

• or directly via a Controller that would create all the required internal resource when detecting the presence of a builder string in the Image declaration.

Thanks for reading!

[anthonydahanne]

👋

[tomkennedy513]

Hey Anthony! For this particular use case you might be best served by using the build resource directly since it just takes a cluster builder image

[tomkennedy513]

The kp improvement would be a pretty cool feature though

[driv]

The tutorial makes this extremely confusing, why hide the easy way?

Hey Anthony! For this particular use case you might be best served by using the build resource directly since it just takes a cluster builder image

You are refering to https://github.com/buildpacks-community/kpack/blob/main/docs/buildpacks.md right?

[anthonydahanne]

You are refering to https://github.com/buildpacks-community/kpack/blob/main/docs/buildpacks.md right?

Yes.
It's also confusing that actually (Cluster)Store are apparently not mandatory