feat: Advanced Templating

[astorath]

1. Added helmfile build command to print final state
   Motivation: useful for debugging purposes and some CI scenarios
2. Template interpolation is now recursive (you can cross-reference release fields) like:

templates:
  release:
    name: {{`app-{{ .Release.Namespace }}`}}
    namespace: {{`{{ .Release.Labels.ns }}`}}
    labels:
      ns: dev

3. Experimental: Added some boolean release fields interpolation in templates:

templates:
  release:
    name: {{`app-{{ .Release.Namespace }}`}}
    namespace: dev
    installedTemplate: {{`{{ eq .Release.Namespace "dev" }}`}}

this solves: #818

4. Added more template interpolations: Labels, SetValues
5. Added template interpolation for inline Values
6. Added helmfile list command to print target releases in simple tabular form
7. Added release names in some helm output messages, e.g.: Comparing release=%v, chart=%v

TODO:

• add some docs
• add values (full) templating
• make some yaml serialization improvements

[mumoshu]

@astorath Hey! Thanks a lot for your efforts.

I'm looking forward to review this fully once this gets out of the WIP status.

Until then I'll keep adding design comments. Firstly:

Template interpolation is now recursive (you can cross-reference release fields) like:

How the dependencies across field templates are handled? Do you by any chance build something like a DAG of field templates?

Experimental: Added some boolean release fields interpolation in templates:

This makes sense. An alternative way to that is to give boolean field interface{} types and render it when and only when the actual value type was string. Have you considered it? If so, would u mind sharing why you prefer doing it with another -Template fields?

Added helmfile state command to print final state
Motivation: useful for debugging purposes and some CI scenarios

Awesome!

Can I later enhance it so that the output of the state command can be fed into helmfile apply for reproducible and audited deployments?

Actually I'm talking about #780 so I'd be glad if I can rename it to helmfile build. Thoughts?

[astorath]

@mumoshu

How the dependencies across field templates are handled? Do you by any chance build something like a DAG of field templates?

No, just simple iterations with some sane limit. If release stops mutating: interpolation stops.

This makes sense. An alternative way to that is to give boolean field interface{} types and render it when and only when the actual value type was string. Have you considered it? If so, would u mind sharing why you prefer doing it with another -Template fields?

Well, I do consider my approach ugly. But I don't think that messing with HelmSpec (changing some field types) is a good option: all consumers would have to cast those or use some getters on public field...

As I've pointed out, the best way (IMHO) is to separate HelmSpec and HelmTemplateSpec. Maybe treat HelmTemplateSpec as map[string]interface{}. But this approach requires a lot of effort and my humble golang knowledge is not enough for such an endeavour...

Nevertheless, if you think using interface{} for those fields with some getter methods is a better option - this is definitely an option.

Actually I'm talking about #780 so I'd be glad if I can rename it to helmfile build. Thoughts?

I've replaced the name.

[mumoshu]

This looks neat!

[mumoshu]

helmfile list and helmfile build with support for templating non-string release fields! LGTM. Thanks a lot for your AWESOME work @astorath 🎉

[mumoshu]

No, just simple iterations with some sane limit. If release stops mutating: interpolation stops.

Understood. As long as someone tries 6+ iterations in a real world project(not sure someone ever does!), we can live with that, which makes me think that it's a great starting point.

the best way (IMHO) is to separate HelmSpec and HelmTemplateSpec

I agree a lot!

Maybe treat HelmTemplateSpec as map[string]interface{}

This may negate my previous comment but I started thinking that both map[string]interface{} and overloading makes it harder for users to enable/disable templating on the specific field(name, namespace, tillerless and so on there will be no prob. I'm curious about values and set)

The way you've done things with the -Template suffix would never suffer from that, which is good.

Probably I'll adapt existing fields like values and set to be more specific about templating enablement in the future.

[mumoshu]

Accordingly to #823 (comment), I'd be happy if we could enable templates only for setTemplate and valuesTemplate rather than set and values respectively.

I'll make the changes on my own before releasing this, but if you made it on your side I'd be happy to review/accept the PR! Thanks.

[mumoshu]

See #833

[mumoshu]

Merged #833. Please feel free to leave any comments about it!