Consider these module calls:
{{ module "prodHelmDeploy" "overrides" {"replicas": 4} }}
{{ module "devHelmDeploy" "overrides" "{\"replicas\": 4}" }}
When rendered in module using var function, they end up becoming map[replicas:4] instead of {"replicas": "4"}.
I created this go playground: https://play.golang.org/p/L7UseCdYgMo to find the root cause and looks like implementation of parseValue is to be blamed for this. If parseValue was similar to renderValue, we wouldn't have run into this.
Please run the playground code to see it in action. I have copied code from parse.go.
A workaround I found for this issue was to put a space before beginning "{" in value to avoid check in parseValue function.
As a side note, why does dinghy use "var" function and all this parsing to allow access to these variables. Wouldn't passing these variables in a map to template be easier and allow much more control to the users of templates? For example, helm passes .Values map to templates. A variable map combined with functions from #122 would allow a lot of flexibility and avoid these bugs.
Consider these module calls:
When rendered in module using var function, they end up becoming
map[replicas:4]instead of{"replicas": "4"}.I created this go playground: https://play.golang.org/p/L7UseCdYgMo to find the root cause and looks like implementation of
parseValueis to be blamed for this. IfparseValuewas similar torenderValue, we wouldn't have run into this.Please run the playground code to see it in action. I have copied code from parse.go.
A workaround I found for this issue was to put a space before beginning "{" in value to avoid check in
parseValuefunction.As a side note, why does dinghy use "var" function and all this parsing to allow access to these variables. Wouldn't passing these variables in a map to template be easier and allow much more control to the users of templates? For example, helm passes .Values map to templates. A variable map combined with functions from #122 would allow a lot of flexibility and avoid these bugs.