Compatibility with helm's --set-file when?

[BogdanSorlea]

Hey,

I have helm charts developed in a specific way that is meant to also facilitate usage by users with less tech ability,
meaning they can easily edit the application config by amending a file containing a (yaml) key: value list, which list is then used in a helm template which creates a custom, overriding ConfigMap:

{{- if .Values.env }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-myservice-custom
  namespace: myservice
  labels:
    stack: {{ .Release.Name }}
    service: myservice
data:
{{ .Values.env | indent 2 }}
{{- end }}

... as long as I pass it to the helm upgrade command using --set-file - so an example command would be:

helm upgrade --install mystack --set-file=mystack.myservice.custom.config

where an example mystack.myservice.custom.config file can look like this:

APP_DEBUG: "true"
APP_LOCALE: en
DB_HOST: db.mystack.mydomain.net

Now while I could supposedly generate the ConfigMap outside helm and inject it by specifying it in a HelmRelease manifest, I find it unacceptable, both because of our other specific orchestration and our specific needs, but also because this would be just a workaround stemming from a contract incompatibility.

So then the question is: when are you going to address this and actually support a --set-file-equivalent declaration in HelmRelease - and anywhere else where it might be applicable?

I hope my example is clear enough. Looking forward for a positive answer.

[jmcenteeIV]

I see a lot of thumbs up on this, so there seems like there is a lot of agreement with the sentiment you are posting here. I have not had an issue with the tooling provided today (ConfigMap with values for the HelmRelease) so was hoping you can go into more detail of your circumstances (or anyone who has agreed) as to why this doesnt work for you. Thanks!