Structure like this:

chart.yaml
values.yaml
templates/
|__deploymentconfig.yaml

Usage: helm install demo --dry-run --debug -f values.yaml

What i like to do is, to add an environment variable with the --set command on helm install after the template has filled the yaml.

Dummy Command like this (not working):
helm install demo ... -f values.yaml --set ???env[0].name=MyEnvVar

Resulting deployment config should look like this:

kind: Deployment
...
spec:
  template:
    spec:
      containers:
        env:
          - name: MyEnvVar
            value: Hello

What do i need to set on the ??? part of the install command to get the desired variable in the deployment part of the manifest?

CodePudding user response：

In a comment you clarify:

I would like to add an environment variable without touching the Helm code (only using --set on CLI)

You can't use helm install --set to make any changes that aren't described in the template code. If your chart says, for example,

env:
  - name: SOME_VARIABLE
    value: {{ .Values.someValue | default "foo" }}

then you could helm install --set someValue=bar to change the one specific environment value, but your chart itself has no way to supply additional environment variables, and --set on its own can't change this.

Reason: No Test Code goes to production.

You can still allow customizing the chart without breaking this rule. If "is it production" controls a specific set of things, you can make that a deploy-time control

env:
  - name: ENVIRONMENT
    value: {{ Values.environment | default "production" }}

helm install --set environment=development ...

Or you could provide an open-ended set of extension environment variables, expecting that to normally be empty

env:
{{- with .Values.extraEnvironment }}
{{ toYaml . | indent 2 }}
{{- end }}

The corresponding helm install --set syntax for this would be trickier, but you could write a separate YAML file of deploy-time values to inject with helm install -f.

In principle you could use post rendering to make arbitrary changes to the deployed YAML, and that could include adding environment variables. That's a complex approach, though, and it leaves you in the situation of having tested something with modifications from the standard deployment; that might not be reproducible enough for many needs.