-
Notifications
You must be signed in to change notification settings - Fork 176
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
Feature request: Zarf dev package templating #2631
Comments
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 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. |
An example of this with helm is
which will output the templates with the variables filled in. Zarf should have a similar option. |
Thank you for this issue, it was part of the inspiration for https://github.com/zarf-dev/proposals/blob/main/0008-rework-inspect/README.md, which was recently approved and will be implemented |
Closing this, will update with the issues that come out of https://github.com/zarf-dev/proposals/blob/main/0008-rework-inspect/README.md. |
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: