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
Is your feature request related to a problem? Please describe.
It would be beneficial if zarf had the ability to template out what would be in a package at create time and also at deploy time with input variables. It is sometimes difficult to determine what will happen with a complex zarf package with component imports, overrides etc.
Describe the solution you'd like
Given I'm creating a zarf package
When I type zarf dev package template create (or something like this) with --set variables or referencing a zarf.config
Then Zarf will
template and print the Zarf package with templated ###ZARF_PKG_TMPLs rendered
template and print the values.yaml files with ###ZARF_VARs- defaults used if none provided by the user at create time
template and print all manifests that the helm charts would create with ###ZARF_VARs - defaults used if none provided by the user at create time
When I type zarf dev package template deploy (or something like this) with --set variables or referencing a zarf.config
Then Zarf will
template and print the Zarf package with templated ###ZARF_PKG_TMPLs rendered
template and print the values.yaml files with ###ZARF_VARs- possibly defaults used
template and print all manifests that the helm charts would create with ###ZARF_VARs - possibly defaults used if none provided by the user at deploy time
Additional context
I feel like this workflow eases the friction of needing to actually have a kubernetes cluster up and running and allows you to debug zarf package templating logic before applying anything to a cluster - similar to the way helm template works, but with the additional zarf templating on top of it.. This makes the feedback loop smaller when debugging a zarf package that is failing to deploy.
The text was updated successfully, but these errors were encountered:
I'll second this feature request. Not having an easy way to see the rendered yaml also made diagnosing this bug a bit tricky: #2692
Note that if the problem is in the values.yaml and it makes the yaml invalid, then a ctrl-c mid attempt to make it work will preserve the rendered yaml in your /tmp directory and you can view it there.
This command is also said to result in the full manifests because 'kind' is in all manifests:
zarf dev find-images . --flavor upstream --why "kind"> templated.txt
Final note: this zarf functionality should also be expanded into UDS since UDS is frequently the entrypoint to the package creation and deployment commands.
Is your feature request related to a problem? Please describe.
It would be beneficial if zarf had the ability to template out what would be in a package at create time and also at deploy time with input variables. It is sometimes difficult to determine what will happen with a complex zarf package with component imports, overrides etc.
Describe the solution you'd like
zarf dev package template create
(or something like this) with--set
variables or referencing a zarf.config###ZARF_PKG_TMPL
s rendered###ZARF_VAR
s- defaults used if none provided by the user at create time###ZARF_VAR
s - defaults used if none provided by the user at create timezarf dev package template deploy
(or something like this) with--set
variables or referencing a zarf.config###ZARF_PKG_TMPL
s rendered###ZARF_VAR
s- possibly defaults used###ZARF_VAR
s - possibly defaults used if none provided by the user at deploy timeAdditional context
I feel like this workflow eases the friction of needing to actually have a kubernetes cluster up and running and allows you to debug zarf package templating logic before applying anything to a cluster - similar to the way
helm template
works, but with the additional zarf templating on top of it.. This makes the feedback loop smaller when debugging a zarf package that is failing to deploy.The text was updated successfully, but these errors were encountered: