Helmfile: Arg -e does not work when working with seperate environments file and multiple helmfiles

[tstmrk]

I have got the following situation, 3 files.

• helmfile.yaml
• nginx.yaml
• environments.yaml

helmfile.yaml

helmfiles:
  - nginx.yaml

environments.yaml

environments:
  default:
    values:
      - nginx:
          host: something.local
  develop:
    values:
      - nginx:
          host: something.local

nginx.yaml

bases:
  - environments.yaml
---
releases:
  - name: nginx
    chart: bitnami/nginx
    values:
      - hosts:
        - name: {{ .Values.nginx.host }}
          path: /

helmfile build works fine (selecting default values from environments.yaml)

PS E:\home\workspace\helm\github-1142\mumoshu> helmfile build
---
#  Source: nginx.yaml

filepath: nginx.yaml
environments:
  default:
    values:
    - nginx:
        host: something.local
  develop:
    values:
    - nginx:
        host: something.local
bases:
- environments.yaml
releases:
- chart: bitnami/nginx
  name: nginx
  values:
  - hosts:
    - name: something.local
      path: /
templates: {}
---
#  Source: helmfile.yaml

filepath: helmfile.yaml
helmfiles:
- path: nginx.yaml
  environment: {}
templates: {}

When passing the environment variabel I get an error message

PS E:\home\workspace\helm\github-1142\mumoshu> helmfile -e develop build
err: no releases found that matches specified selector() and environment(develop), in any helmfile

While is goes well when I pass the file argument

PS E:\home\workspace\helm\github-1142\mumoshu> helmfile -f .\nginx.yaml -e develop build
---
#  Source: nginx.yaml

filepath: nginx.yaml
environments:
  default:
    values:
    - nginx:
        host: something.local
  develop:
    values:
    - nginx:
        host: something.local
bases:
- environments.yaml
releases:
- chart: bitnami/nginx
  name: nginx
  values:
  - hosts:
    - name: something.local
      path: /
templates: {}

In my 2nd case I expect helmfile to select the variables belonging to the develop environment. Am I doing something wrong here is is it a bug. Thanks in advance! :-)

Version info

PS E:\home\workspace\helm\github-1142\mumoshu> helmfile --version
helmfile version v0.102.0

[mumoshu]

@tstmrk Hey! Thanks for trying Helmfile. I'm not yet sure whether I should consider this as a bug, or not.

Basically, this is a duplicate of https://github.com/roboll/helmfile/issues/704#issuecomment-503647741. As of today you can't define only helmfiles: within a helmfile.yaml. You can add a few releases in the helmfile.yaml to make it work.

Maybe this is an unnecessary restriction? Would you be happy if I just changed the behavior of helmfile to allow helmfiles: only helmfile.yaml?

[tstmrk]

I was following the example helmfile given @ https://github.com/cloudposse/helmfiles#configuration, so I thought it would work.

When I add one more release to the helmfile.yaml, it is still not working. (same error)

helmfiles:
  - nginx.yaml
---
releases:
  - name: nginx2
    chart: bitnami/nginx
    values:
      - hosts:
        - name: bla
          path: /

I just realized that if I rewrite my helmfile.yaml like below then it is working, so that is my work around.

bases:
  - environments.yaml
---
helmfiles:
  - nginx.yaml

But isn't it more DRY to have it in one place? Like _or_ in the helmfile.yaml and when it's not there then in nginx.yaml?

Edit
My mentioned work around does not work when working the seperate values files in seperate folders, because it has some trouble with finding the files (I guess due to different relative paths)

[mumoshu]

Ah okay that makes sense!

So the general rule here is that (as of today) Helmfile requires at least one release in each helmfile for the target environment. That is, you need the develop environment defined in both helmfile.yaml and nginx.yaml.

That's why your latter example works.

We needed some balance between DRY and explicitness. With the current helmfile behavior, you are always sure that all the sub-helmfiles has support for the target environment. In other words, when you add a new environment later, you can notice any problematic sub-helmfile that misses the new env.

[tstmrk]

True! And clear, so I am getting it now. I was thinking too complex I guess :-) Thanks for your clarification!