helmfile icon indicating copy to clipboard operation
helmfile copied to clipboard

Emacs-style comment break state file processing when non-default environment used

Open evgkrsk opened this issue 4 years ago • 5 comments

How to reproduce

~/tmp/helmfile ❯ helmfile --version                                                                                                                                                                                                                                                                 
helmfile version v0.139.9

MacOS 11.4, x86_64, helmfile installed via brew

Create helmfile.yaml file:

# -*- mode: yaml; mode; view -*-
---
environments:
  bootstrap:
releases:
  - name: k8s-iae
    chart: sb/k8s-iae

and try to apply/render YAML/render values

Actual result

~/tmp/helmfile ❯ helmfile write-values
Writing values file helmfile-0c6885e8/k8s-iae.yaml
~/tmp/helmfile ❯ helmfile -e bootstrap write-values
err: no releases found that matches specified selector() and environment(bootstrap), in any helmfile

Expected result

~/tmp/helmfile ❯ helmfile write-values
Writing values file helmfile-0c6885e8/k8s-iae.yaml
~/tmp/helmfile ❯ helmfile -e bootstrap write-values
Writing values file helmfile-0c6885e8/k8s-iae.yaml

Workarounds found so far

---
environments:
  bootstrap:
releases:
  - name: k8s-iae
    chart: sb/k8s-iae

or

# -*- mode: yaml; mode; view -*-
environments:
  bootstrap:
releases:
  - name: k8s-iae
    chart: sb/k8s-iae

or

environments:
  bootstrap:
releases:
  - name: k8s-iae
    chart: sb/k8s-iae

evgkrsk avatar Jun 26 '21 09:06 evgkrsk

# any comment
---
environments:
 example

I believe the example above results in two YAML documents, and the first is empty, which obviously contains no release specs for helmfile to parse.

Perhaps you could use a local variables list near the near the end of the file instead.

yurrriq avatar Nov 29 '21 18:11 yurrriq

The YAML specification example 2.7 implies that

# any comment
---
environments:
 example

would be only 1 YAML document.

scruffaluff avatar May 20 '22 05:05 scruffaluff

It might be more about that helmfile doesn't allow empty helmfile.yaml part, as it can't decide if the user mistakenly created an empty YAML doc part in helmfile.yaml or it's intended.

mumoshu avatar May 20 '22 05:05 mumoshu

I'd consider this a bug. Consider the following helmfile.

# A comment.
---
environments:
  default:
    values:
      - label: "I was parsed from the default environment."
  other:
    values:
      - label: "I was parsed from the other environment."

releases:
  - name: ingress-nginx
    chart: ingress-nginx/ingress-nginx
    namespace: ingress-nginx
    values:
      - commonLabels:
          label: {{ .Environment.Values.label }}

repositories:
  - name: ingress-nginx
    url: https://kubernetes.github.io/ingress-nginx

The command helmfile --environment default template will parse the values label from the default environment and add it to commonLabels in the ingress-nginx release.

However, the command helmfile --environment other template will result in error err: no releases found that matches specified selector() and environment(other), in any helmfile.

Thus helmfile does allow the empty helmfile YAML part only for the default environment, but will not allow the empty helmfile YAML part for other environments.

P.S. I understand that Helmfile development has migrated to https://github.com/helmfile/helmfile. If you prefer, I can file this as an issue there.

scruffaluff avatar May 21 '22 18:05 scruffaluff

@scruffaluff Thanks for clarifying!

The intention here is helmfile should fail like err: no releases found that matches specified selector() and environment(other), in any helmfile on empty helmfile part and helmfile.yaml, regardless of the user chosen the default env or the named env(like other).

So, if it was a bug, we'd need to "fix" it to also fail for the former case, which is still not what you want.

mumoshu avatar May 22 '22 05:05 mumoshu