mirror of
https://github.com/helm/helm.git
synced 2026-02-23 10:00:21 -05:00
* Remove Tiller reference from the docs Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com> * Update comments after review - https://github.com/helm/helm/pull/4788#discussion_r226037034 - https://github.com/helm/helm/pull/4788#discussion_r226037064 - https://github.com/helm/helm/pull/4788#discussion_r226037806 - https://github.com/helm/helm/pull/4788#discussion_r226038492 - https://github.com/helm/helm/pull/4788#discussion_r226039202 - https://github.com/helm/helm/pull/4788#discussion_r226039894 Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
30 lines
1.1 KiB
Markdown
30 lines
1.1 KiB
Markdown
# Debugging Templates
|
|
|
|
Debugging templates can be tricky because the rendered templates are sent to the Kubernetes API server, which may reject the YAML files for reasons other than formatting.
|
|
|
|
There are a few commands that can help you debug.
|
|
|
|
- `helm lint` is your go-to tool for verifying that your chart follows best practices
|
|
- `helm install --dry-run --debug`: We've seen this trick already. It's a great way to have the server render your templates, then return the resulting manifest file.
|
|
- `helm get manifest`: This is a good way to see what templates are installed on the server.
|
|
|
|
When your YAML is failing to parse, but you want to see what is generated, one
|
|
easy way to retrieve the YAML is to comment out the problem section in the template,
|
|
and then re-run `helm install --dry-run --debug`:
|
|
|
|
```YAML
|
|
apiVersion: v1
|
|
# some: problem section
|
|
# {{ .Values.foo | quote }}
|
|
```
|
|
|
|
The above will be rendered and returned with the comments intact:
|
|
|
|
```YAML
|
|
apiVersion: v1
|
|
# some: problem section
|
|
# "bar"
|
|
```
|
|
|
|
This provides a quick way of viewing the generated content without YAML parse
|
|
errors blocking.
|