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
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.
The text was updated successfully, but these errors were encountered:
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
parseValue
is to be blamed for this. IfparseValue
was 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
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.
The text was updated successfully, but these errors were encountered: