You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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!
The text was updated successfully, but these errors were encountered:
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: