feat: Allow environment values to be specified on the CLI

[dtshepherd]

Allow environment values to be specified on the CLI:

helmfile --environment default --set foo.bar=123

Not sure what the CLI switch should be named and whether it should allow at the global level or only an option on sync, charts, template.

[mumoshu]

I think this is useful, but on the other hand I'm afraid this defeats the original purpose of environments and environment values, that is to ensure environments are reproducible.

[mumoshu]

What are exact use-case(s) of this?

[dtshepherd]

:) This all boils down to templating values.yaml files and it seems .Environment (and env) are the only ways to push data into the templates. Hence, being able to override specific values on the CLI would be nice. Similar to how helm template works.

[mumoshu]

Thanks!

I was thinking that it would be preferable to use something like {{ env "IMAGE_TAG }} in environment values gotmpl files when, for example, you want to inject a value from a CI build. Or {{ exec "./your-arbitraty-source" }} to inject it from any source. That works like a documentation of what's required in order to apply your helmfile to the environment. In other words, I thought --set is unclear about where the value should come from.

So, it is just that I'm probably wondering about what would --set allow me to do in addition to env values gotmpl files.

[bitsofinfo]

@mumoshu @dtshepherd I was just about to create my own issue about this, but agree w the OP that something is needed

I really would like to be able to do something like this as well

helmfile --environment default --set-value foo.bar=123 --set-env TEST_VAR=dog

Where:

• --set-value overrides any thing in the default helmfile environment with matching value path of foo.bar
• --set-env simply is a convenience that would set real ENVIRONMENT vars rather than me having to EXPORT them prior to running the helmfile command (i.e. these vars would just be accessible like {{ env TEST_VAR }} as normal, but its just a nice to have CLI flag.

i.e. I dislike having to do this:

EXPORT TEST_VAR=dog; helmfile --environment default 

[mumoshu]

@bitsofinfo Thanks as always for your feedback!

--set-value overrides any thing in the default helmfile environment with matching value path of foo.bar

Yeah! This should be added.

Just to share the idea with you, I was in the impression that we'd end up adding --values FILE that allows you to set environment values from the FILE, as similar as helm --values FILE vs helm --set KEY=VALUE.

--set-env seems to worth a dedicated issue. Would you mind submitting one? Also, something like --set-env-file may make sense as well as --values FILE.

[bitsofinfo]

@mumoshu my biggest caution however is to ensure solid naming/docs around this. It could be easy for users to get confused by system ENVIRONMENT variables in the traditional sense, vs Chart values, vs *helmfile .Environment.Values. etc. Naming is critical

maybe

• --set-helmfile-env-value foo.bar=x
• --set-helmfile-env-values-file [pathToYamlValuesFile]
• --set-env-var ENV_VAR=x
• --set-env-vars-file [pathToENVvarFile]

[mumoshu]

I can't agree more! So I even started to consider migrating to a term like State Values rather than Environment Values.

[mumoshu]

BTW, here's a related discussion regarding this specific feature: --set #398 (comment)

[mumoshu]

For more context, I think we have a feature request that breaks .Environment.Values if done straightforward #398 (comment)

Alternatively, we can change the term to State Values, and:

• Make it accessible in the template with .Values(not .Environment.Values)

• Explicitly note in the documentation that Environment Values is for overriding (State) Values

• Deprecate .Environment.Values and recommend using .Values.

• .Values can be overrode with command-line args and environment values files(Question: How to handle global variables across helmfiles #398 (comment))

  # Internally this is an alias of `environments.default.values`
  values:
  - myAPIEndpoint: https://dev.example.com/
     mykey: myvalue
  
  environments:
    production:
      values:
      - myAPIEndpoint: https://prod.example.com/
  

  When --environment production

  • {{ .Environment.Values.mykey }} fails(This preserves the existing behavior)
  • {{ .Values.mykey }} results in myvalue cuz .Values is environments.default.values + environments.production.values

• It's .Values so the command-line args to set it from k-v pairs would naturally look like helmfile --set KEY=VALUE

• The command-line args to set it from a file it looks like helmfile --values FILE

• We recently implemented feat: specify env values from the parent to the nested state #622 but it should be changed. Use helmfiles[].values rather than helmfiles[].environment.values make it similar to its command-line flag variant --values.

  helmfiles:
  - name: sub.helmfile.yaml
    values:
      mykey: myvalue
  

• helmfile --environment NAME remains as-is. It set's the state's environment name.

• helmfile --set-envvar NAME=VALUE, helmfile --envvar-set, or helmfile --envvar sets envvars from NAME=VALUE pairs.

• helmfile --envvars-file FILE, or helmfile --envvars FILE sets environment variables from the FILE

For envvars, I personally prefer the combo of helmfile --envvars-file FILE and helmfile --envvar-set NAME=VALUE, as it seems user-friendly because (1)they naturally collocate in the flags list thati s alphabetically sorted (2) it's harder to confuse with --environment NAME.