docs(values,templating): add reference and best practices pages - #4368
docs(values,templating): add reference and best practices pages#4368mkcp wants to merge 13 commits into
Conversation
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
✅ Deploy Preview for zarf-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
…em rather than duplicating the same content Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
…nd config file imports and --set-values Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
|
|
||
| See the [Templating Reference](/ref/templating/) for complete function documentation. | ||
|
|
||
| ## Avoid Sensitive Data in Values Files |
There was a problem hiding this comment.
Generally this is good advice but I do think it is worth calling out that values files will be the primary mechanism for orchestrating sensitive values. Given the declarative delivery model - all secrets have to originate from somewhere.
It will be important for sunsetting zarf variables as it will provide a way to break these out of zarf config files.
We may want to delineate between sensitive values defaults getting "baked" into the package - for which you had a few good examples of different environment overrides that would align to that story telling.
There was a problem hiding this comment.
This is a good callout - I rewrote this section to highlight not committing secrets to package defaults, and gave examples of how they can be passed in.
|
|
||
| ## Common Errors and Solutions | ||
|
|
||
| ### Template Parse Errors |
There was a problem hiding this comment.
++ I like that we are making errors in docs discoverable.
|
|
||
| ::: | ||
|
|
||
| Zarf supports Go template syntax and `text/template` engine with powerful features including control flow and functions. Zarf includes the full library of [Sprig functions](http://masterminds.github.io/sprig/) and some builtins for dynamic configuration in manifests, files, and actions. This powerful templating system enables complex transformations, conditional logic, and data manipulation beyond simple string substitution. |
There was a problem hiding this comment.
This may be a good place to identify what is different between zarf templating and helm templating.
There was a problem hiding this comment.
I added some notes about the similarities and differences here
AustinAbro321
left a comment
There was a problem hiding this comment.
Leaving comments on the review so far, I'll aim to do a review on the ref section at another point
There was a problem hiding this comment.
Across this PR we reference zarf package inspect, zarf dev inspect and using the values schema however none of these features are merged into Zarf as of yet. IMO we should wait until a feature is merged before documenting it
There was a problem hiding this comment.
I believe that this is addressed now
|
|
||
| ## Provide Defaults for Optional Values | ||
|
|
||
| Use the `default` function to provide fallback values: |
There was a problem hiding this comment.
While defaults are generally a good practice, I don't think they really make sense in the context of Zarf since we always validate that there is a value for template. I could be missing scenarios but AFAIK there is no way for the default to come into play
| data: | ||
| # Numbers must be strings in ConfigMaps | ||
| port: {{ .Values.app.port | toString | quote }} | ||
| replicas: {{ .Values.app.replicas | toString | quote }} | ||
|
|
||
| # Booleans to strings | ||
| debug: {{ .Values.app.debug | toString | quote }} | ||
|
|
||
| # ❌ RISKY: Type mismatch errors | ||
| data: | ||
| port: {{ .Values.app.port }} # May fail if port is a number |
There was a problem hiding this comment.
Numbers don't have to be strings in configmaps, Kubernetes will store either
There was a problem hiding this comment.
Thoughts on generalizing the example a bit then, like "explicit type conversion may be necessary?"
|
|
||
| ## Handle Missing Values Gracefully | ||
|
|
||
| Protect against missing or nil values: |
There was a problem hiding this comment.
I don't think this advice makes sense in the context of Zarf, the "good" example will still fail if .values.monitoring.enabled is not set
There was a problem hiding this comment.
Yeah I agree, I don't like encouraging conditional blocks like this either. Removed in latest
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
brandtkeller
left a comment
There was a problem hiding this comment.
Minor comments as I iterate through some tests - otherwise I like how clean and comprehensive this is.
|
|
||
| ## Do Not Commit Sensitive Values in Package | ||
|
|
||
| Values are the best way to pass secrets into your Zarf package, but those secrets should not be baked into the values files a package is created with: |
| - `name`: The path where the value should be stored (e.g., `database.password`) | ||
| - `type`: The format of the output - `string` (default), `json`, or `yaml` | ||
|
|
||
| Values set via `setValues` are available in subsequent actions and manifests within the same deployment. |
There was a problem hiding this comment.
Making a note in-passing that an example here may be valuable (is that a pun?) - will resolve if included elsewhere.
| order: 10 | ||
| --- | ||
|
|
||
| This guide provides best practices for using [Package Values](/ref/package-values/) in your Zarf packages. |
There was a problem hiding this comment.
It's briefly touched on in the ref document - but If I think of the ref document as the "how" and best practices as the "why" - I wonder if a good addition here could be the mention of why the use of granular sourcePath/targetPath. Security considerations and treating it as an allow list as well as traceability when we think about potential collisions with on-deployment values files and the future of imports.
Signed-off-by: Kit Patella <kit@defenseunicorns.com>
|
Closing as completed in #5090 |
Description
Add reference and best practices documentation for package values and templating.
Related Issue
Relates to #3946
Checklist before merging