Templatize "metadata" files in helm charts

[Cryptophobia]

From @arschles on June 28, 2016 18:8

This issue is for using Go templates in Chart.yaml and README.md files in helm charts so that deisrel doesn't have to do string replacement, which is brittle. My proposal is to add a generate_metadata.toml in the same directory as the README.md and the Chart.yaml, and make the latter two files into Go templates. deisrel would then get a new command that reads the generate_metadata.toml and generates the README.md and Chart.yaml templates based on the values in that file.

In this new scheme, a new workflow-tpl folder would be created in the https://github.com/deis/charts repository. That repo would have a README.md that looks similar to the below, with a similar Chart.yaml file as well.

# Workflow {{.WorkflowVersion}}

{{.WorkflowWarning | default "WARNING: this chart is for testing only! Features may not work, and there are likely to be bugs."}}

Please report any issues you find in testing Workflow to the appropriate GitHub repository:
{{range .WorkflowComponents}}
- {{.Name}}: {{.Link}}
{{end}}

A version-specific file would be created by the releaser to cut a new chart. This file would not necessarily need to be checked in to any source control, because it's only used once. See below for a sample:

WorkflowVersion = "v2.0.0"
WorkflowWarning = ""
[WorkflowComponents]
builder = "https://github.com/deis/builder"
...

With those changes in place, the deisrel command to create a new template would be as follows:

deisrel helm tpl ./workflow-tpl ./workflow-2.1.0 --params=workflow-2.1.0-metadata.toml

This command would not only create a new chart based on workflow-2.1.0-metadata.toml, it would also adjust the tpl/generate_params.toml so that helmc generate can correctly generate new manifests when the user is installing deis workflow. The latter is current behavior of deisrel.

cc/ @vdice for thoughts and feedback

Copied from original issue: deis/deisrel#103

[Cryptophobia]

From @vdice on June 28, 2016 20:2

@arschles this looks good!

My only suggestion, and this is a post-proposal, implementation detail, is to use .WorkflowDescription as opposed to .WorkflowWarning in the README.md template example above. (The default description would then be the WARNING... string (or whatever it may evolve to) and then it can be set to something else as shown in the example above.)