-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify user experience: have kpack define (Cluster)Store, (Cluster)Builder and (Cluster)Stack from a CNB builder #1163
Comments
👋 |
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 |
The kp improvement would be a pretty cool feature though |
The tutorial makes this extremely confusing, why hide the easy way?
You are refering to https://github.com/buildpacks-community/kpack/blob/main/docs/buildpacks.md right? |
Yes. |
In the
kpack
tutorial, the following steps:seem to add some burden to the usability of
kpack
; for example, reference toolpack
or other popular integrations such asspring boot maven plugin
orwaypoint
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 anImage
definition:The notable difference with the existing
kpack.io/v1alpha2:Image
is that thebuilder
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 builderwould 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
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 topack config default-builder paketobuildpacks/builder:0.2.316-full
builder
string in theImage
declaration.Thanks for reading!
The text was updated successfully, but these errors were encountered: