remove the "gotmpl" extension for template values

[sgandon]

following the comment here : #388 (comment)
I was simply wondering why there is a difference between plain values and templated ones.
In other term what would it cost to consider all values files as templates whatever their name cause running the template engine on a plain yaml should not fail anyway.
That would make things much easier.

[sgandon]

for instance I was using the simple .yaml file and not I need to templatize it.
So I need to change the extension and then change all helmfiles that reference it.

[mumoshu]

There were edge cases that you need to write golang text templates as plaintext, like writing Prometheus Alertmanager config 😄

[mumoshu]

I was even considering to make .gotpl necessary in order to template the whole helmfile.yaml. To me, the fact helmfile.yaml isn't an actual YAML has been confusing.

[sgandon]

indeed I see your case I don't mind either way. And you are right .yaml file for go template is not the ideal extension.

[sebastien-prudhomme]

@mumoshu I've just discovered the edge case for Prometheus AlertManager and was surprised by the fact that helmfile.yaml is a template.

It seems that it's possible to change the curly bracket separator with other separator. Have you considered that option?

[mumoshu]

@sebastien-prudhomme Hey!

I've considered that, but had no idea how we could cleanly implemented it. Are you aware of any way to instruct golang text/template to use another separator?

[sebastien-prudhomme]

@mumoshu Here they talk about the Delims function: https://stackoverflow.com/questions/17641887/how-do-i-escape-and-delimiters-in-go-templates

[yeusiukou]

@mumoshu one issue with *.yaml.gotmpl extension is that we lose yaml syntax highlighting in major code editors and GitHub. Would it make sense to have it the other way around: *.gotmpl.yaml?

[mumoshu]

@Xroker Hey! Thanks for the idea. But I don't think that's "correct", as it isn't a YAML file in the first place. A valid go-template file that generates a YAML can easily be an invalid YAML file. .gotmpl.yaml seems to hide that fact.

[yeusiukou]

@mumoshu Fair enough, I can see such cases. But for the users who are confident in "validity" of the yaml files, what do you think about allowing both .yaml.gotmpl and .gotmpl.yaml? Because it doesn't seem to be any other way to make helmfile interpolate the templates.

[mumoshu]

@Xroker Just to be sure- you use go templates but still want it it look like a regular YAML to IDE?

If it's a plain YAML without go template you can just use .yaml.

Just asking because I'm not sure how .gotmpl.yaml can be justified as a template. If the last suffix was .yaml, I'd make Helmfile rather parse it as a YAML first, and then render the YAML as a go template. That's opposite of the current behaviour for .yaml.gotmpl. Also, I don't think how blocks of large-scoped if and for works in .gotmpl.yaml. Can we write it as a valid YAML when you need to template the whole structure of your values file using if and for?

[yeusiukou]

@mumoshu I was thinking about simpler cases such as the one described here: https://github.com/roboll/helmfile#environment-values

In the example, releases in helmfile.yaml reference to values.yaml.gotmpl, which pulls environment-specific values. In my case, only some values are environment-specific, the rest of the document is pure yaml. But because I need to inject these custom values I'm trading off the convenience of syntax highlighting.

Could you clarify why you believe that the file extension format should dictate the order of parsing? This seems to be open for interpretation and can vary in different applications.

[mumoshu]

Could you clarify why you believe that the file extension format should dictate the order of parsing? This seems to be open for interpretation and can vary in different applications.

Just my common sense. Can you expect foo.tar.gz to be a tar containing a single gzipped file?(It's gzipped tar) Also, can you read some.mp4.zip to be a mp4 "of" a zip file which doesn't make sense at all? It's more natural to read the latest suffix as the actual file extension.

[mumoshu]

In the example, releases in helmfile.yaml reference to values.yaml.gotmpl, which pulls environment-specific values. In my case, only some values are environment-specific, the rest of the document is pure yaml. But because I need to inject these custom values I'm trading off the convenience of syntax highlighting.

Can you just separate values.yaml.gotmpl and values.yaml and benefit the IDE syntax highlighting on values.yaml only, in your release? Only the dynamic part needs to be in values.yaml.gotmpl.

[balusarakesh]

it would be great if there is a solution for this issue

I can't find a single extension for VS code to highlight values.yaml.gotmpl, I understand it is not really a yaml file but for our use case 95% of the content in .values.yaml.gotmpl is in yaml format and it is not very easy to read a non-highlighted file in any IDE

[yeusiukou]

@balusarakesh I ended up setting the following in settings.json:

"files.associations": {
    "*.yaml.gotmpl": "yaml"
}

[balusarakesh]

I did something like that, for anyone interested here's a link