@PatrykKlimowicz Please fix DCO issue.

Why not use installed field?

Hey @PatrykKlimowicz! Thanks for your contribution.
I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

Every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?

Sorry if I lost memory or missed something. Thanks in advance for your help!

Why not use installed field?

Correct me if I'm wrong, but releases marked with installed: false will be uninstalled in the next sync. With this proposal this won't be the case.

Hey @PatrykKlimowicz! Thanks for your contribution. I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

Every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?

Sorry if I lost memory or missed something. Thanks in advance for your help!

Sorry, I do not have the possiblity to provide the full description now. However, there is no inheritance between envs, they are still independent. I will update later today/tomorrow morning with the examples.

Hey @PatrykKlimowicz! Thanks for your contribution. I've just started reviewing this, and I'd appreciate it if you could confirm one thing;

can be minimized to:

Every non-all environment seem to inherit missing values from the all environment. How does it work...? I thought that's not how helmfile is supposed to work. Without that, new the syntax like condition: '{{ .Values | get "foo.enabled" "false" }}' would be equivalent to today's condition: foo.enabled?

Sorry if I lost memory or missed something. Thanks in advance for your help!

Ok, found some time to sit in front of my laptop. Right now there is a need to specify the envs as following:

environments:
  foo:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: false
      - bar:
           enabled: false
  boo:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: true
      - bar:
           enabled: false
  bar:
    values:
      - foo:
           enabled: false
      - boo:
           enabled: false
      - bar:
           enabled: true

and this is because of how condition has to be specified. Helmfile is forcing the approach of foo.enabled, hence we have to repeat the values to make the following works:

releases:
  - name: foo
    chart: ./foo
    condition: 'foo.enabled'
    values:
      - ./foo/values-extra.yaml

  - name: boo
    chart: ./boo
    condition: 'boo.enabled'
    values:
      - ./boo/values-extra.yaml

  - name: bar
    chart: ./bar
    condition: 'bar.enabled'
    values:
      - ./bar/values-extra.yaml

so if we ran the helmfile -e foo diff the conditions for boo and bar releases will be evaluated, it will turn out that value is false, so only foo will be enabled. But all used values in condition field must be defined for given environment.

This PR gives us possibility to minimize the code duplication in the environments section thanks to the use of get template function that provides us opportunity to specify the fallback value. We can do the following:

environments:
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values
      - bar:
           enabled: true

However, to avoid panic in the ConditionEnabled function we have to change the way of defining the value in condition field. What we are looking for is the actual value of this foo.enabled var passed in example above. To be precise, string that can be converted to boolean. Now, the releases will look as following:

---
releases:
  - name: foo
    chart: ./foo
    condition: '{{ .Values | get "foo.enabled" "false" }}' # obtain value or fallback
    values:
      - ./foo/values-extra.yaml

  - name: boo
    chart: ./boo
    condition: '{{ .Values | get "boo.enabled" "false" }}' # obtain value or fallback
    values:
      - ./boo/values-extra.yaml

  - name: bar
    chart: ./bar
    condition: '{{ .Values | get "bar.enabled" "false" }}' # obtain value or fallback
    values:
      - ./bar/values-extra.yaml

After we ran the helmfile -e foo apply command, get function will try to obtain the values for foo.enabled, boo.enabled, bar.enabled vars, but we know that only foo.enabled is defined, hence for other two the fallback value false will be used as the entry for condition field. Since it is a string that we can convert to bool, both boo and bar releases won't be applied.

In the current approach of helmfile, we have to specify the default values in the each environment. This PR does not impact the helmfiles that people has created already. It also does not change the default helmfile behavior. It adds possibility to use the "special" strings as the value for condition field and thanks to the usage of get template function we can specify defaults in inline manner.

Why this is important to have this possibility?
Current helmfile # releases / # loc in whole environments section:

• 2/12 - 6 lines per release
• 3/24 - 8 lines per release
• 4/40 - 10 lines per release
• 5/60 - 12 lines per release
• 6/84 - 14 lines per release

With this PR we can achieve # releases / # loc in whole environments section:

• 2/8 - 4 lines per release
• 3/12 - 4 lines per release
• 4/16 - 4 lines per release
• 5/20 - 4 lines per release

Happy to answer some more questions 😄

To give you some insights how exactly the code change is working:

1. If condition is not defined or is "" return true, nil immediately
2. If condition is string that is convertible to boolean, return it's bool representation
3. Check if passed string which is referencing variable follows the convention of 'foo.enabled'
4. Process given var, and return true/false

@PatrykKlimowicz Thanks for clarifying! Ah gotcha! So the key idea in this pull request is that you define default values in get template function calls in, whereas "ideally," the default and override values are defined under environments... correct?

Presuming that's correct, how about implementing some kind of "inheritance" to environments instead, like we've done for templates/releases in #606?

It could be implemented to look like this:

environments:
    # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true
  # One release at time starts here
  foo:
    inherit:
      environment: all
    values:
      - foo:
           enabled: true
  boo:
    inherit:
      environment: all
    values:
      - boo:
           enabled: true
  bar:
    inherit:
      environment: all
    values:
      - bar:
           enabled: true

or to avoid mixing "template" environments (like "all", which is not supposed to be used directly via -e all) and regular environments-

environmentTemplates:
    # one env to rule them all
  all:
    values:
      - foo:
           enabled: true
      - boo:
           enabled: true
      - bar:
           enabled: true

environments:
  # One release at time starts here
  foo:
    inherit:
      template: all
    values:
      - foo:
           enabled: true
  boo:
    inherit:
      template: all
    values:
      - boo:
           enabled: true
  bar:
    inherit:
      template: all
    values:
      - bar:
           enabled: true

or more simply, introduce some defaults like helmDefaults for `releases[]-

environmentDefaults:
  # one env to rule them all
  values:
  - foo:
       enabled: true
  - boo:
       enabled: true
  - bar:
       enabled: true

environments:
  # One release at time starts here
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values:
      - bar:
           enabled: true

@mumoshu The key idea is to make the hardcoded nature of condition field more flexible. As a result this is possible:

define default values in get template function calls

The proposals you've made are kind of interesting! I'd say environmentDefaults is more elegant way of what I made with get template function.

I really like the clean nature of inherit + environmentsTemplate approach. Since it has been already implemented in the other places I believe it's good idea to "extend" this keyword on the environments section as well. I can work on this proposal - no problem 😄

Anyway, the idea from this PR can be independent from the inherit approach. Is there any strong reason that condition can only be foo.enabled and not true or false explicitly? And why only two levels of nesting are valid? Why we cannot use variable like foo.release.enabled? The hardcoded nature of this field is really strange. As you can see, the possiblity to pass to condition strings that can be evaluated to bool is pretty powerful and is achievable with small amount of changes in the code.

To sum up, it would be really nice to have this inherit functionality with environments section (I can create PR for that) AND it would be nice to make the condition field more flexible. WDYT?

@mumoshu any decisions? 😄

Is there any strong reason that condition can only be foo.enabled and not true or false explicitly?

Yes! That is to make the condition field look very similar to helm's Chart.yaml condition field, with takes a path in values.yaml.

Is there any strong reason that condition can only be foo.enabled and not true or false explicitly?

Yes! That is to make the condition field look very similar to helm's Chart.yaml condition field, with takes a path in values.yaml.

Ok, I'll propose this inherit + environmentsTemplate functionality in the new PR then 😄

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@PatrykKlimowicz any updates?

you could define "default" values to false and only the overrides in environments:

values:
      - foo:
           enabled: false
        boo:
           enabled: false
        bar:
           enabled: false

environments:
  all:
    values:
      - foo:
           enabled: true
        boo:
           enabled: true
        bar:
           enabled: true
  foo:
    values:
      - foo:
           enabled: true
  boo:
    values:
      - boo:
           enabled: true
  bar:
    values:
      - bar:
           enabled: true

@PatrykKlimowicz any updates?

Sorry, got stuck with other work. I'll open PR tomorrow

I suggest to extend it not only for bools, but also for other types - see my topic in discussions: #926

@JuryA Hey! Please also see this one #913 (comment) In short, I'm doubting that we are about to outgrow yaml + go template based solution....

@JuryA Hey! Please also see this one #913 (comment) In short, I'm doubting that we are about to outgrow yaml + go template based solution...

Greetings. Apologies for the delayed response. I've taken some time to evaluate the benefits of both Jsonnet and CUE. Both have their unique advantages and optimally, supporting both would be beneficial. However, I understand this might complicate the codebase.

The immediate issue to address is the unavailability of some key fundamental information. Currently, obtaining this data requires cumbersome, less-than-ideal methods. This problem is magnified when considering cross-platform compatibility, affecting Windows, Linux, and macOS. Fortunately, one can rely on Git for this purpose. For example, on Windows, we can use:

git -c 'alias.cmd=!<some command> <its_args>' cmd

It's a somewhat inelegant and hacky solution, isn't it? 😬 But it ensures that the command will execute in Git Bash on Windows and in a suitable shell on other POSIX platforms.

It would be advantageous to directly provide some well-known information at runtime by Helmfile itself among other objects.

For example:

Helmfile Root Directory:

values:
  - Helmfile:
      Paths:
        helmfileRoot: !!str {{ exec "git" (list "-c" "alias.pwd=!pwd" pwd) | trim | osClean }}

PWD:

{{ $PWD := env "PWD" | osClean }}

Pertinent Paths:

{{ $Helmfile := .Values | get "Helmfile" (dict) }}
{{ $Self := $Helmfile | get "Self" (dict) }}
{{ $helmfilePath := $Self | getOrNil "helmfilePath" }}
{{ $helmfileDir := $helmfilePath | osDir }}
{{ if not $helmfilePath }}
  {{ print "\n\n.Values.Helmfile.Self.helmfilePath not defined!\n\n" | fail }}
{{ end }}

Other Paths:

  - Helmfile:
      Self:
        helmfileDir: &helmfileDir {{ $helmfileDir | osClean | quote }}
        helmfilePath: &helmfilePath {{ $helmfilePath | osClean | quote }}
        helmfileName: {{ $helmfilePath | osBase | quote }}
      Paths:
        helmfileDir: *helmfileDir
        helmfilePath: *helmfilePath

... and many others...