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
First, I would like to say thanks for this great piece of tool. I can imagine I will use it a lot.
I would like to propose some feature addition that rises from the needs of maintaining my own helm charts.
Background
I managed helm chart recipe where some of the services are needed as dependencies to other charts.
Some chart bootstrap other charts from one single values.yaml file. To support some customization in the chart dependencies, some of the values needs to be clearly defined and interlinked (definition of possible values for chart A may reuse or refer the original definition of values in chart B). To support this kind of use case, I propose the following feature additions:
Proposed features
Support for tpl string
Some dependent chart's values needs to be injected from original chart via Go template string. A value that need a go template string can be like this:
When chart was generated, the value awesomeApp.siteUrl is set dynamically at generation time as https://mysite.org. However, currently helm-docs will generate the default value of awesomeApp.siteUrl as a JSON escaped string. This doesn't look easy to understand because it will only be a one line string with some escaped character.
I would like to be able to show the default value as:
siteUrl: |
https://{{ .Values.global.sitename }}
This way, user understands that the value expects a Go template string.
Support for non JSON default value rendering
In some cases, rendering the escaped JSON values looks very complicated. There is also another reason where I want the user to replace a value with a valid YAML structure, but since the default value is rendered as JSON, it looks misleading.
I want the default value to be rendered in YAML like this for the key parent.child:
name: "honk"age: 13hobby: "sleeping"
Support for custom value types
Currently, the value types are recognized directly from the YAML structure.
However in some cases, the value types have a clear defined structure that can be referenced elsewhere. Like k8s docs, other chart, or simple structure like email, URL, filepath, csv etc.
I would like to be able to put my own custom type like this:
# -- (string/email) This is a user email typeemail: [email protected]# -- (string/url) This has to be formatted as URLurl: https://somesite.org
At least these types can be parsed and rendered in the values table.
Support for custom notation types
Even if two values use string, that doesn't mean it should be rendered the same way in the default value column.
In some chart, I can put my own configuration file inside the values.yaml so that it can be included in the configmap.
All of it are string value, but we can improve the rendering to match the language syntax.
I propose we add another annotation: @notationType that can tell you what type of rendering it we should use.
# -- This is string, but should be rendered as python file# @notationType -- pythondjangoSettings: | import os # something pythony# -- This is string, but can be rendered as nginx config file# @notationType -- nginxnginxConfig: | # nginx server block server { location / { # some nginx config } }
The rendering itself is a separate issue, but I was hoping that the @notationType was parsed first and available inside the template.
Support for more flexible value table rendering
My above use case seems to need the table to be generated directly as HTML tags.
I can do it myself, totally separate from helm-docs, however if this can be merged and supported, it would be good.
Basically the current values table are rendered using Github Markdown, from markdown syntax. But if we can provide HTML tags rendering, this would be possible:
Default values can be rendered as <pre> tag, multiline. So we can pretty print the default behaviour of rendering the default values as JSON
There's no way for me to display YAML or Go template string in one line using current markdown table syntax. I had to do it multiline using HTML table tags combined with codefence or <pre> tag directly.
Specifying id in the <td> or <tr> tag of the value rows can create anchor that can be referenced inside the markdown, or across the page. So my chart A can refer to value documentation at chart B.
Custom rendering the Type columns, so that it will hyperlinked to the data structure/value structure definition somewhere
Custom rendering the Default value columns, so that it appropriately consider @notationType and render suitable color syntax or format
I think, we can keep the usual value section in markdown and this HTML tables as separate template definition.
The text was updated successfully, but these errors were encountered:
Hi @norwoodj .
First, I would like to say thanks for this great piece of tool. I can imagine I will use it a lot.
I would like to propose some feature addition that rises from the needs of maintaining my own helm charts.
Background
I managed helm chart recipe where some of the services are needed as dependencies to other charts.
Some chart bootstrap other charts from one single
values.yaml
file. To support some customization in the chart dependencies, some of the values needs to be clearly defined and interlinked (definition of possible values for chart A may reuse or refer the original definition of values in chart B). To support this kind of use case, I propose the following feature additions:Proposed features
Support for tpl string
Some dependent chart's values needs to be injected from original chart via Go template string. A value that need a go template string can be like this:
When chart was generated, the value
awesomeApp.siteUrl
is set dynamically at generation time ashttps://mysite.org
. However, currently helm-docs will generate the default value ofawesomeApp.siteUrl
as a JSON escaped string. This doesn't look easy to understand because it will only be a one line string with some escaped character.I would like to be able to show the default value as:
This way, user understands that the value expects a Go template string.
Support for non JSON default value rendering
In some cases, rendering the escaped JSON values looks very complicated. There is also another reason where I want the user to replace a value with a valid YAML structure, but since the default value is rendered as JSON, it looks misleading.
If the
values.yaml
looks like this:I want the default value to be rendered in YAML like this for the key
parent.child
:Support for custom value types
Currently, the value types are recognized directly from the YAML structure.
However in some cases, the value types have a clear defined structure that can be referenced elsewhere. Like k8s docs, other chart, or simple structure like
email
,URL
,filepath
,csv
etc.I would like to be able to put my own custom type like this:
At least these types can be parsed and rendered in the values table.
Support for custom notation types
Even if two values use string, that doesn't mean it should be rendered the same way in the default value column.
In some chart, I can put my own configuration file inside the
values.yaml
so that it can be included in the configmap.All of it are string value, but we can improve the rendering to match the language syntax.
I propose we add another annotation:
@notationType
that can tell you what type of rendering it we should use.The rendering itself is a separate issue, but I was hoping that the
@notationType
was parsed first and available inside the template.Support for more flexible value table rendering
My above use case seems to need the table to be generated directly as HTML tags.
I can do it myself, totally separate from
helm-docs
, however if this can be merged and supported, it would be good.Basically the current values table are rendered using Github Markdown, from markdown syntax. But if we can provide HTML tags rendering, this would be possible:
<pre>
tag, multiline. So we can pretty print the default behaviour of rendering the default values as JSON<pre>
tag directly.<td>
or<tr>
tag of the value rows can create anchor that can be referenced inside the markdown, or across the page. So my chart A can refer to value documentation at chart B.Type
columns, so that it will hyperlinked to the data structure/value structure definition somewhereDefault
value columns, so that it appropriately consider@notationType
and render suitable color syntax or formatI think, we can keep the usual value section in markdown and this HTML tables as separate template definition.
The text was updated successfully, but these errors were encountered: