Open omnilinguist opened 6 years ago
Probably just dead code. We can clean that up.
well, the point is not only to clean up the dead code, but to actually pass through the helm interface (hence the issue subject) :)
We have a very similar setup: values.yaml
in root of a chart with common properties, and a few values.yaml
files in environments/<env>/
folders, and some secrets that are always being passed as a param to helm
.
It seems draft
can read the parent values.yaml
, and it has an interface to configure secrets (in draft.toml in set
list), but there is no way to tell draft to also look in environments/dev/values.yaml
just like I would do it with helm ... -f environments/dev/values.yaml
.
@bacongobbler from what I can see these constants aren't used anywhere in draft, should we keep them?
- // ChartfileName is the default Chart file name.
- ChartfileName = "Chart.yaml"
- // ValuesfileName is the default values file name.
- ValuesfileName = "values.yaml"
- // IgnorefileName is the name of the Helm ignore file.
- IgnorefileName = ".helmignore"
- // DeploymentName is the name of the deployment file.
- DeploymentName = "deployment.yaml"
- // ServiceName is the name of the service file.
- ServiceName = "service.yaml"
- // IngressName is the name of the ingress file.
- IngressName = "ingress.yaml"
- // NotesName is the name of the NOTES.txt file.
- NotesName = "NOTES.txt"
- // HelpersName is the name of the helpers file.
- HelpersName = "_helpers.tpl"
- // TemplatesDir is the relative directory name for templates.
- TemplatesDir = "templates"
Noticed that in the file https://github.com/Azure/draft/blob/4a298770ff4484e5737fabf4bb9abc54b6b72e7c/pkg/draft/pack/pack.go#L19-L20, there is a section
However, this constant doesn't seem to be used anywhere else in the codebase, which makes me wonder how it gets used by draft, and why this code is in the draft repository at all. The answer seems to be in https://github.com/kubernetes/helm/blob/cf3ded91f2143fed6850dee70630c1049bf937ec/pkg/chartutil/create.go#L31-L32, but whereas there is a way to configure this in helm via
helm ... -f values_env.yaml
, the draft wrapper doesn't seem to expose this functionality.A more general version of this, of course, would be to have a more direct interface with the underlying helm commands that get invoked for advanced users.
Use case for this (the shrewd reader may again sense a CI/CD flavour here) is that if an application's chart has multiple values YAMLs for different environments (staging, production), it would be possible to toggle easily between the two rather than having to have complex toggling constructs in the Helm template files.