Operating system

mac

Helmfile Version

4e9b99d (master)

Helm Version

n/&

Bug description

helmfile -l name=hazelcast apply
Error: unknown shorthand flag: 'l' in -l

Example helmfile.yaml

Error message you've seen (if any)

Error: unknown shorthand flag: 'l' in -l

Steps to reproduce

helmfile -l name=hazelcast apply

Working Helmfile Version

v0.144

Relevant discussion

No response

Operating system

MacOS Monterey 12.3

Helmfile Version

Helmfile version 0.0.0-dev, main branch @ 9af8f12

Helm Version

version.BuildInfo{Version:"v3.9.2", GitCommit:"1addefbfe665c350f4daf868a9adc5600cc064fd", GitTreeState:"clean", GoVersion:"go1.18.4"}

Bug description

With multiple helmfile specifying releases for different environments, all releases are being included despite not matching the environment specified on the command line.

Example helmfile.yaml

environments:
  development: {}

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: cache
    namespace: my-app
    chart: bitnami/redis
    version: 17.0.7

environments:
  test: {}

repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: database
    namespace: my-app
    chart: bitnami/postgres
    version: 11.6.22

Error message you've seen (if any)

No error message, results are unexpected

Steps to reproduce

https://github.com/dackroyd/helmfile-release-environment-bug

Working Helmfile Version

helmfile version v0.145.2

Relevant discussion

No response

Operating system

os x

Helmfile Version

canary

Helm Version

n/a

Bug description

before cobra migration:
--environment value, -e value specify the environment name. defaults to "default"

after cobra migration (#234):
-e, --env string specify the environment name. defaults to "default"

the environment long option changed from --environment to --env

Example helmfile.yaml

n/a

Error message you've seen (if any)

Error: unknown flag: --environment

Steps to reproduce

helm --environment myenv template

Working Helmfile Version

v0.145.0

Relevant discussion

No response

Add DCO verify in ci

Discussed in #119

Operating system

ubuntu:20.04

Helmfile Version

0.144.0

Helm Version

3.8.2

Bug description

Hi, helmfile apply seems to not use .Capabilities.KubeVersion.Version from the cluster.
The command translates to helm upgrade --install ... as it is the first install. The implicit diff before sync (that is what apply does if I'm not mistaken) seems to work because it sees the resources as new. (Or is that determined by detecting no previous helm secret for that release?)

What can we do to make apply get the correct .Capabilities.KubeVersion.Version from the cluster? Your docs say that it is deprecated in v3 but that is NOT true: https://helm.sh/docs/chart_template_guide/builtin_objects/#helm

I provided a link to our repo which has docs here: otomi.io, but I guess that won't be needed to discuss my observation.

Steps to reproduce

https://github.com/redkubes/otomi-core

Relevant discussion

No response

Operating system

Ubuntu 20.04

Helmfile Version

v0.144.0

Helm Version

v3.7.2

Bug description

The colored output for helmfile diff is not working in the Docker container due to version v3.3.1 of the helm diff plugin being used in the image.

v3.4.0 of helm-diff fixes this. Therefore the Docker image should be updated to install latest version of helm-diff which is by now v3.5.0

We've tested this and with the new version setting and setting the environment variable as discussed here, colored output is working.

Steps to reproduce

n/a

Relevant discussion

roboll/helmfile#2043 (comment)

Operating system

macOS 12.5.1

Helmfile Version

v0145.4

Helm Version

version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.19"}

Bug description

I have multiple helmfiles in my project. Some releases in those helmfiles "need" other releases. There is a singular helmfile at the root, which references helmfiles by means of the helmfiles configuration property.

If a release needs another which has not yet been reached, helmfile fails. This means I have to make sure I order the helmfiles in a specific way to get needs dependencies to work. With glob patterns, this is not possible, and sometimes it's logically impossible as there could be a non-trivial dependency tree.

In my mind (and I'm surprised it isn't this way) it seems as though helmfile needs to gather all releases and do the dependency resolution afterwards.

Have I misunderstood the use of needs or is this just a limitation of the implementation?

Example helmfile.yaml

# Root helmfile
helmfiles:
  - apps/*/helmfile.yml

---

# apps/myapp1/helmfile.yml
releases:
  - name: myapp1
    needs:
      - myapp2

---

# apps/myapp2/helmfile.yml
releases:
  - name: myapp2

Error message you've seen (if any)

Error: in ./helmfile.yaml: in .helmfiles[0]: in apps/***/helmfile.yml: release(s) "***/***" depend(s) on an undefined release "***/***". Perhaps you made a typo in "needs" or forgot defining a release named "***" with appropriate "namespace" and "kubeContext"?
in ./helmfile.yaml: in .helmfiles[0]: in apps/***/helmfile.yml: release(s) "***/***" depend(s) on an undefined release "***/***". Perhaps you made a typo in "needs" or forgot defining a release named "networking" with appropriate "namespace" and "kubeContext"?

Steps to reproduce

N/A

Working Helmfile Version

N/A

Relevant discussion

No response

Operating system

Ubuntu 22 & Manjaro

Helmfile Version

0.144.0

Helm Version

3.9.0

Bug description

I have a helmfile with a global "cleanup" hook and a "postsync" and "postuninstall" hook per-release. Everything works like a charm for both "sync" and "destroy" commands and the "cleanup" hook is always executed after all the releases have been processed.

However, when I start using nested states, the global "cleanup" hook for the "destroy" command gets executed at the beginning of the process, right after logging into the registry.

I honestly don't understand this behavior and I don't see it documented anywhere.

Any insight will be welcome,

Thanks in advance

Steps to reproduce

https://github.com/teksuo/helmfile-nested-hook-bug

Relevant discussion

No response

Operating system

Ubuntu 20.04.4 LTS

Helmfile Version

0.145.3

Helm Version

3.9.0

Bug description

If I using the associated helmfile.yaml run helmfile --namespace hello-there list it will as expected print:

NAME     	NAMESPACE  	ENABLED	INSTALLED	LABELS	CHART        	VERSION
service-a	hello-there	true   	true     	      	incubator/raw	

However, if I only specify the shorthand option for namespace using helmfile -n hello-there list an error is raised:
Error: unknown shorthand flag: 'n' in -n

Using the -n option was at least working in 0.142.0 and should work according to documentation.

Example helmfile.yaml

repositories:
- name: incubator
  url: https://charts.helm.sh/incubator
---
releases:
- name: service-a
  chart: incubator/raw
  namespace: {{ .Namespace }}

Error message you've seen (if any)

Error: unknown shorthand flag: 'n' in -n

Steps to reproduce

N/A

Working Helmfile Version

0.142.0

Relevant discussion

No response

Operating system

macOS 12.15.1

Helmfile Version

v0145.4

Helm Version

version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.19"}

Bug description

When I run sync with the --interactive flag, I do not get a confirmation before helmfile makes changes to my cluster.

Example helmfile.yaml

N/A

Error message you've seen (if any)

N/A

Steps to reproduce

N/A

Working Helmfile Version

N/A

Relevant discussion

No response

Operating system

macOS Monterey 12.4

Helmfile Version

0.144.3

Helm Version

3.9.0

Bug description

When using helmfile diff with the context option, the full template is always displayed.

Example helmfile.yaml

This applies to any Helmfile that will detect changes between the local state and the running state.

Error message you've seen (if any)

No error messages are reporting.

Steps to reproduce

None available.

Working Helmfile Version

0.144.2

Relevant discussion

No response

Operating system

Mac OS 12.0.1

Helmfile Version

0.144.0

Helm Version

v3.7.2

Bug description

SSH bin is absent in helmfile dockerimage.

Images affected:
quay.io/roboll/helmfile:v0.144.0-stable-slim
quay.io/roboll/helmfile:v0.144.0

Steps to reproduce

1. Helmfile.yaml:

helmfiles:
- path: git::ssh://[email protected]/repo.git@helm/helmfile.yaml?ref=master

...

2. Try to sync/template/test with cmd:

docker run --rm --net=host -v "${KUBECONFIG}:/root/.kube/config" -v "${PWD}:/wd" --workdir /wd quay.io/roboll/helmfile:v0.144.0 helmfile template

Actual result:

in ./helmfile.yaml: in .helmfiles[0]: locate: get: error downloading 'ssh://[email protected]/repo.git@helm/helmfile.yaml?ref=master': /usr/bin/git exited with 128: Cloning into '/root/.cache/helmfile/ssh_server_org_repo_git.ref=master'...
error: cannot run ssh: No such file or directory
fatal: unable to fork

Relevant discussion

No response

Operating system

N/A

Helmfile Version

LATEST

Helm Version

LATEST

Bug description

update tag url location.

Steps to reproduce

N/A

Relevant discussion

N/A

Operating system

MacOS 12.4

Helmfile Version

v0.145.0

Helm Version

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}

Bug description

After upgrading helmfile 0.144 -> 0.145 (roboll->helmfile) it fails to run "deps" for plain-YAML releases (for chartify) . Rollback to 0.144 fixes problem.

Example helmfile.yaml

releases:
- name: gitlab-rbac
  chart: ./helmfiles/gitlab-rbac # <- dir with plain yaml manifests

Error message you've seen (if any)

err 3: command "/opt/homebrew/bin/helm" exited with non-zero status:

PATH:
  /opt/homebrew/bin/helm

ARGS:
  0: helm (4 bytes)
  1: dependency (10 bytes)
  2: update (6 bytes)
  3: ./helmfiles/gitlab-rbac (23 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  Error: Chart.yaml file is missing

COMBINED OUTPUT:
  Error: Chart.yaml file is missing

Steps to reproduce

Make helmfile.yaml for plain-yaml release, run "helmfile deps" for it

Relevant discussion

No response

Operating system

macOS 12.3.1

Helmfile Version

0.145.2

Helm Version

v3.9.0

Bug description

File extension .yml is not supported for local manifests.

Example helmfile.yaml

repositories:

• name: jetstack
  url: https://charts.jetstack.io

releases:

• name: cert-manager
  namespace: cert-manager
  chart: jetstack/cert-manager
  version: 1.8.1
• name: cluster-issuer
  namespace: cert-manager
  chart: ./manifests # See here. This fails if .yml is placed into the directory instead of .yaml

Error message you've seen (if any)

n ./helmfile.yaml: [assertion failed: unexpected dir entry : it mnust be a abs path]

Steps to reproduce

https://github.com/Weissger/helmfile-yaml-yml

Relevant discussion

No response

Operating system

all

Helmfile Version

all

Helm Version

all

Bug description

PATH:
/usr/local/bin/helm

ARGS:
0: helm (4 bytes)
1: template (8 bytes)
2: argo-cd-crds (12 bytes)
3: /home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds (110 bytes)
4: --namespace (11 bytes)
5: helmfile-tests-20220825-113625 (30 bytes)

ERROR:
exit status 1

EXIT STATUS
1

STDERR:
Error: path "/home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds" not found

COMBINED OUTPUT:
Error: path "/home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds" not found

Example helmfile.yaml

None

Error message you've seen (if any)

PATH:
/usr/local/bin/helm

ARGS:
0: helm (4 bytes)
1: template (8 bytes)
2: argo-cd-crds (12 bytes)
3: /home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds (110 bytes)
4: --namespace (11 bytes)
5: helmfile-tests-20220825-113625 (30 bytes)

ERROR:
exit status 1

EXIT STATUS
1

STDERR:
Error: path "/home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds" not found

COMBINED OUTPUT:
Error: path "/home/runner/.cache/helmfile/argo-cd-crds/https_github_com_argoproj_argo-helm_git.ref=main/charts/argo-cd/crds" not found

Steps to reproduce

None

Working Helmfile Version

None

Relevant discussion

No response

Operating system

macOS 11.4

Helmfile Version

v0.145.2

Helm Version

v3.9.1

Bug description

In OCI mode, when the url in repositories contains semicolon :, OCI Url and Version will parse error

Example helmfile.yaml

repositories:
 - name: my-oci-repo
   url: "registry:443/helm-charts"
   oci: true

releases:
- name: nginx
  chart: my-oci-repo/nginx-ingress
  version: 0.14.0
  set:
  - name: controller.hostNetwork
    value: true

Error message you've seen (if any)

Pulling registry:443/helm-charts/nginx-ingress:0.14.0
Exporting registry:443/helm-charts/nginx-ingress:0.14.0
Error: in examples/helmfile.yaml: [release "nginx": command "/usr/local/bin/helm" exited with non-zero status:

PATH:
  /usr/local/bin/helm

ARGS:
  0: helm (4 bytes)
  1: fetch (5 bytes)
  2: oci://registry (14 bytes)
  3: --version (9 bytes)
  4: 443/helm-charts/nginx-ingress (29 bytes)
  5: --destination (13 bytes)
  6: /var/folders/r1/6m48m2zj0dd2973tyc9lgxtm0000gp/T/chart3285243845 (64 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  Error: invalid_reference: missing repository

COMBINED OUTPUT:
  Error: invalid_reference: missing repository]
in examples/helmfile.yaml: [release "nginx": command "/usr/local/bin/helm" exited with non-zero status:

PATH:
  /usr/local/bin/helm

ARGS:
  0: helm (4 bytes)
  1: fetch (5 bytes)
  2: oci://registry (14 bytes)
  3: --version (9 bytes)
  4: 443/helm-charts/nginx-ingress (29 bytes)
  5: --destination (13 bytes)
  6: /var/folders/r1/6m48m2zj0dd2973tyc9lgxtm0000gp/T/chart3285243845 (64 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  Error: invalid_reference: missing repository

COMBINED OUTPUT:
  Error: invalid_reference: missing repository]

Steps to reproduce

None

Working Helmfile Version

None

Relevant discussion

No response

Discussed in #155

Operating system

ubuntu

Helmfile Version

canary

Helm Version

n/a

Bug description

helmfile --help produce a warning instead of the help:

helmfile --help
WARNING: pflag: help requested

it looks like the issue decribed in kubernetes/minikube#9614

Example helmfile.yaml

n/a

Error message you've seen (if any)

WARNING: pflag: help requested

Steps to reproduce

helmfile --help

Working Helmfile Version

v0.144.0

Relevant discussion

No response

Operating system

Arch Linux

Helmfile Version

0.144.0

Helm Version

3.9.0

Bug description

Why?

environments:
  default:
    values:
      - hello: world

releases:
...
#  - name: hello
#    namespace: hello
#    chart: ./charts/hello
#    values:
#      - hello: {{.Values.whatever}}

Steps to reproduce

http://here

Relevant discussion

No response

Operating system

Arch Linux

Helmfile Version

0.144.0

Helm Version

3.9.0

Bug description

repositories:
  - name: apisix
    url: https://charts.apiseven.com

missingFileHandler: Error

environments:
  default:
    values:
      - etcd:
          replicaCount: 1
          global:
            storageClass: manual
          persistence:
            storageClass: manual
            size: 4Gi
      - etcdStorage:
          enabled: true

releases:
  - name: etcd-storage
    namespace: apisix
    chart: ./charts/etcd-storage
    condition: etcdStorage.enabled # should be etcd.persistance.enabled but requires helmfile fix
    values:
      - etcd: {{ toYaml .Values.etcd | nindent 10 }}

  - name: apisix
    namespace: apisix
    chart: apisix/apisix
    values:
      - etcd: {{ toYaml .Values.etcd | nindent 10 }}
      - ingress-controller:
          enabled: true
          config:
            apisix:
              serviceNamespace: apisix
...

I have 3 charts. Third chart is a deployment with a service. The etcd-storage is just a manually defined PersistentVolume.

helmfile template works just fine.

Running like this causes Error: Failed to render chart: exit status 1: Error: failed to download "apisix/apisix".

Reordering the first 2 charts causes Error: Failed to render chart: exit status 1: Error: Kubernetes cluster unreachable: Get "https://k8s:6443/version": dial tcp: lookup k8s on <gateway-ip>:53: read udp <host-ip>:49631-><gateway-ip>:53: i/o timeout.

helmfile apply with commented etcd-storage chart works just fine. Running apply with all 3 chars afterwards works just fine as well.

Steps to reproduce

http://here

Relevant discussion

No response

Operating system

ubuntu 20.02.4

Helmfile Version

v3.3.4+5.el8

Helm Version

v3.3.4+5.el8

Bug description

The helm upgrade command i use: helm upgrade vdu "nodename/charts/podname/templates/values.yaml" --set xx.yyy=2
Error: Error: failed to download "nodename/charts/podname/templates/values.yaml" (hint: running helm repo update may help)

Another issue with kubectl apply -f
Command: kubectl apply -f configmap.yaml
error: error: error parsing configmap.yaml: error converting YAML to JSON: yaml: line 3: did not find expected key

Example helmfile.yaml

NA

Error message you've seen (if any)

NA

Steps to reproduce

No

Relevant discussion

No response

Discussed in #186

Hey,

Our trivy found out that helmfile (0.144.0 - newest version as of today) is affected by a critical vulnerability in go-getter.
These are the corresponding CVEs:

• https://avd.aquasec.com/nvd/cve-2022-26945 (command injection vulnerability)
• https://avd.aquasec.com/nvd/cve-2022-30321 (unsafe download (issue 1 of 3))
• https://avd.aquasec.com/nvd/cve-2022-30322 (unsafe download (issue 2 of 3))
• https://avd.aquasec.com/nvd/cve-2022-30323 (unsafe download (issue 3 of 3))

As helmfile is able to download from foreign sources I assume that helmfile could be tricked into downloading potential harmful files (i.e. via DNS spoofing) and then executing those files as well.

I already found out that a fixed version of go-getter is used in the repository but there was no new release. Based on the criticality of that vulnerability I think publishing a patched version of 0.144.0 would be beneficial.

Best regards,

Bernhard Grün

When clicking New issue there is no option to open a bug report:

This is presumably because of the following error message at https://github.com/helmfile/helmfile/blob/main/.github/ISSUE_TEMPLATE/bug.yml as a result of #134.

Operating system

macOS

Helmfile Version

v0.144.0

Helm Version

v3.8.1

Bug description

I set skipDeps: true but Helmfile continues to update the dependencies.

helmDefaults:
  skipDeps: true

Steps to reproduce

set skipDeps: true

Relevant discussion

No response

Operating system

Ubuntu 20.04

Helmfile Version

v0.144.0

Helm Version

version.BuildInfo{Version:"v3.7.0", GitCommit:"eeac83883cb4014fe60267ec6373570374ce770b", GitTreeState:"clean", GoVersion:"go1.16.8"}

Bug description

This issue was mentioned at roboll/helmfile#2048 (comment) .

Helmfile fails to evaluate a needs: dependency correctly if the entry has KUBECONTEXT/NAMESPACE/RELEASE_NAME structure and KUBECONTEXT contains a forward slash.

AWS EKS Cluster context names usually have this structure: arn:aws:eks:AWS_REGION:AWS_ACCOUNT:cluster/CLUSTER_NAME.

Example helmfile.yaml

  - name: releaseB
    namespace: namespaceA
    kubeContext: arn:aws:eks:us-east-1:1234567890:cluster/myekscluster
    needs:
      - arn:aws:eks:us-east-1:1234567890:cluster/myekscluster/namespaceA/releaseA

Error message you've seen (if any)

in ./helmfile.yaml: release(s) "arn:aws:eks:us-east-1:1234567890:cluster/myekscluster/namespaceA/releaseB" depend(s) on an undefined release "myekscluster/namespaceA/releaseA". Perhaps you made a typo in "needs" or forgot defining a release named "cluster" with appropriate "namespace" and "kubeContext"?

Steps to reproduce

N/A

Relevant discussion

No response

Operating system

Ubuntu 20.004

Helmfile Version

0.145.0

Helm Version

version.BuildInfo{Version:"v3.8.1", GitCommit:"5cb9af4b1b271d11d7a97a71df3ac337dd94ad37", GitTreeState:"clean", GoVersion:"go1.17.8"}

Bug description

When providing needs: we see that releases don't get installed one after the other when using apply, but instead get errors about crds not being available (which are to be applied by chart A, and consume by chart B).

Is this due to diff running on ALL the deps beforehand? (DAG resolution happening beforehand?) I think that should not happen, and every release should just be diffed and installed first, before diffing the next.

Example helmfile.yaml

releases:
releases:

• name: gatekeeper
  installed: true
  namespace: gatekeeper-system
  chart: ../charts/gatekeeper
  disableValidationOnInstall: true
  labels:
  pkg: gatekeeper
  values: ...
• name: gatekeeper-artifacts
  installed: true
  needs: [gatekeeper]
  namespace: gatekeeper-system
  chart: ../charts/gatekeeper-artifacts
  labels:
  pkg: gatekeeper
  values: ...

Error message you've seen (if any)

basically errors about crds not being available when rendering the next in the DAG.

Steps to reproduce

https://github.com/redkubes/otomi-core

Relevant discussion

No response

Operating system

Ubuntu 18.04 LTS

Helmfile Version

0.145.2

Helm Version

v3.9.0

Bug description

Passing the helm upgrade flag "--reuse-values" via the "--args" option to "helmfile sync" and "helmfile apply" has no effect.

Example:
This is a simple helm chart containing one config-map with two values "first_name" and "last_name".
We want to update these values using helmfile following the steps below:

The content of "staging-values-01.yaml":

first_name: "spring"
last_name: "boot"

The content of "staging-values-02.yaml":

last_name: "mvc"

1. Run helmfile for the 1st time:

helmfile -f helmfile.yaml sync --values staging-values-01.yaml

As expected, "first-name" will be "spring" and "last_name" will be "boot".

2. ReRun helmfile with different values:

helmfile -f helmfile.yaml sync --values staging-values-02.yaml --args "--reuse-values"

Let say we want to update only the "last_name" and we omitted "first_name" from the values.yaml since we expect that it will remain the same:

What happens after running the command is that the "last_name" is updated, but the "first_name" which is removed in the "staging-values-02.yaml" has been restored to the default value of the chart instead of remaining at the previous value.

So instead of having "first_name: spring" and "last_name: mvc", we got "fist_name: lorem" and "last_name: mvc"

We observed the same behaviour with "helmfile sync" and "helmfile update".

Otherwise, in case this is expected, how to achieve the desired result of updating only a subset of values, the behavior of "--reuse-values", using helmfile args/options.

Example helmfile.yaml

releases:

• name: simple-chart
  namespace: staging
  chart: ./simple-chart

Error message you've seen (if any)

There is no error message but the result of the execution is not as expected.

Steps to reproduce

https://github.com/Hamdiovish/helmfile-args-report

Relevant discussion

No response

Operating system

MacOS Monterey 12.4

Helmfile Version

v0.145.3

Helm Version

v3.9.3

Bug description

helmfile jsonPatches does not work with packaged (e.g. tgz) charts.

This failure occurs for local and remote charts, but the error returned is different (see below).

It does not fail if the chart is extracted to a directory or is in a helm repository.

The errors appear to be from chartify.

Detailed reproduction steps and --debug output can be found in: https://gist.github.com/seanorama/7640609952b6999b23b761678d226784

Example helmfile.yaml

Using local packaged chart:

releases:
- name: test
  namespace: test
  chart: ./datadog-2.37.4.tgz
  jsonPatches:
    - target:
        kind: ServiceAccount
        name: test-datadog
      patch:
        - op: add
          path: /metadata/annotations
          value:
            foo: bar

Using remote packaged chart:

releases:
- name: test
  namespace: test
  chart: https://github.com/DataDog/helm-charts/releases/download/datadog-2.37.4/datadog-2.37.4.tgz
  jsonPatches:
    - target:
        kind: ServiceAccount
        name: test-datadog
      patch:
        - op: add
          path: /metadata/annotations
          value:
            foo: bar

Error message you've seen (if any)

Detailed --debug error messages are in: https://gist.github.com/seanorama/7640609952b6999b23b761678d226784

Using local packaged chart:

Error: in ./helmfile.yaml: [stat datadog-2.37.4.tgz/kustomization.yaml: not a directory]
in ./helmfile.yaml: [stat datadog-2.37.4.tgz/kustomization.yaml: not a directory]

Using remote packaged chart:

Error: in ./helmfile.yaml: [1 additional files found in temp direcotry. This is very strange]
in ./helmfile.yaml: [1 additional files found in temp direcotry. This is very strange]

Steps to reproduce

https://gist.github.com/seanorama/7640609952b6999b23b761678d226784

Working Helmfile Version

n/a

Relevant discussion

No response

Operating system

Helmfile Version

Helm Version

Bug description

Release 0.145.4 artifacts have wrong names without first dot in version string: "helmfile_01454_checksums.txt" and so on.

Probably root cause is wrongly named git tag: v0145.4 (previous tag was v0.145.3).

Example helmfile.yaml

Error message you've seen (if any)

Steps to reproduce

Working Helmfile Version

0.145.3

Relevant discussion

No response

@jkroepke mentioned in roboll/helmfile#1878 (comment) an upcoming change in helm-secrets which would break helmfile, which has since been released and breaks helmfile. I think the following code section needs to be updated to correspond to the newer helm-secrets behavior that was described in the linked comment:

With the current code, an error occurs whenever using helmfile with helm-secrets and a custom HELM_SECRETS_DEC_SUFFIX and helm-secrets 3.8.2.

Repro: https://github.com/raxod502-plaid/helmfile-issue-1

In that repo with

• helm 3.3.4
• helm-secrets 3.8.2
• helmfile 0.144.0

Then if I run helmfile template it works:

% helmfile template
Decrypting secret /Users/rrosborough/temp/helmfile-repro/secrets.yaml
[helm-secrets] Decrypting /Users/rrosborough/temp/helmfile-repro/secrets.yaml

Building dependency release=hewwo, chart=hewwo
Templating release=hewwo, chart=hewwo

However if I use a custom decryption suffix it is broken:

% HELM_SECRETS_DEC_SUFFIX=.dec helmfile template
Decrypting secret /Users/rrosborough/temp/helmfile-repro/secrets.yaml
[helm-secrets] Decrypting /Users/rrosborough/temp/helmfile-repro/secrets.yaml

open /Users/rrosborough/temp/helmfile-repro/secrets.dec: no such file or directory
open /Users/rrosborough/temp/helmfile-repro/secrets.dec: no such file or directory
in ./helmfile.yaml: failed to read helmfile.yaml: failed loading environment secrets with 1 errors

Furthermore, the file secrets.yaml.dec is created in the repo and is not cleaned up. It seems that helmfile and helm-secrets are in disagreement about the name of the decrypted file.

Note that this worked back in helm-secrets 3.7.0-dev, but it's broken in 3.8.2 due to the aforementioned upstream update.

Using HELM_SECRETS_DEC_SUFFIX is required for our use case due to roboll/helmfile#1878 (comment) to which there does not appear to be another workaround at present.

Operating system

Ubuntu 20.04

Helmfile Version

0.145.3

Helm Version

3.9.3

Bug description

Sync, Diff, template fonction is break with OCI chart when using --selector.

Helm version : 3.8.0
Helmfile version : 0.144.0
Repository : Azure Container Registry

Here the templating without selector

Logging in to registry
Login Succeeded

Pulled: xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Digest: sha256:f19d9413523a99b0a1a351999e0b1c6ab8f3729623077a8fee65a2b629ddac1b

Exporting xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Pulled: xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Digest: sha256:f19d9413523a99b0a1a351999e0b1c6ab8f3729623077a8fee65a2b629ddac1b

Templating release=cfg-shared-configs, **chart=/tmp/helmfile636816509/cfg-shared-configs/cfg-shared-configs/1.0.0/cfg-shared-configs**
---
# Source: cfg-shared-configs/templates/configmaps.yaml
apiVersion: v1
kind: ConfigMap

...

Here the template with --selector (chart=cfg-shared-configs)

Logging in to registry
Login Succeeded

Pulling xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Exporting xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Pulled: xxx.azurecr.io/helm/cfg-shared-configs:1.0.0
Digest: sha256:f19d9413523a99b0a1a351999e0b1c6ab8f3729623077a8fee65a2b629ddac1b

Exporting npd03cacnacrgen.azurecr.io/helm/cfg-shared-configs:1.0.0
Pulled: npd03cacnacrgen.azurecr.io/helm/cfg-shared-configs:1.0.0
Digest: sha256:f19d9413523a99b0a1a351999e0b1c6ab8f3729623077a8fee65a2b629ddac1b

Templating release=cfg-shared-configs, chart=acr/cfg-shared-configs
in ./helmfile.yaml: command "/usr/local/helm/helm" exited with non-zero status:

PATH:
  /usr/local/helm/helm

ARGS:
  0: helm (4 bytes)
  1: template (8 bytes)
  2: cfg-shared-configs (18 bytes)
  3: acr/cfg-shared-configs (22 bytes)
  4: --version (9 bytes)
  5: 1.0.0 (5 bytes)
  6: --namespace (11 bytes)
  7: perf3 (5 bytes)
  8: --values (8 bytes)
  9: /tmp/helmfile639927867/perf3-cfg-shared-configs-values-b68dc94b7 (64 bytes)
  10: --timeout=30m0s (15 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  Error: failed to download "acr/cfg-shared-configs" at version "1.0.0"

COMBINED OUTPUT:
  Error: failed to download "acr/cfg-shared-configs" at version "1.0.0"

Example helmfile.yaml

Helmfile.yaml:

repositories:
  - name: acr
    oci: true
    url: {{ requiredEnv "ACR_URL" | quote }}
    username: {{ requiredEnv "ACR_USER" | quote }}
    password: {{ requiredEnv "ACR_PASSWORD" | quote }}

bases:
  # Tools releases template
  - releases/tool-release.gotmpl

tool-release.gotmpl:

# configmap Release Templating

releases:
{{- if hasKey .Environment.Values "configmap" }}

# Loop on configmap dictionary to prepare release for each of the configmap-* charts
{{ range $chart, $params := .Environment.Values.configmap }}

  - name: {{ $chart }}
  
    chart: acr/{{ $chart }}

    labels:
      chart: {{ $chart }}
{{- end }}
{{- end }}

Error message you've seen (if any)

STDERR:
Error: failed to download "acr/cfg-shared-configs" at version "1.0.0"

COMBINED OUTPUT:
Error: failed to download "acr/cfg-shared-configs" at version "1.0.0"

Steps to reproduce

Private repository

Working Helmfile Version

No one

Relevant discussion

No response

Operating system

centos7

Helmfile Version

v0.144.0

Helm Version

version.BuildInfo{Version:"v3.8.1", GitCommit:"5cb9af4b1b271d11d7a97a71df3ac337dd94ad37", GitTreeState:"clean", GoVersion:"go1.17.5"}

Bug description

args: --output-dir /opt/helmfile_render/
output: /opt/helmfile_render//helmfile-496c211e-test

Steps to reproduce

args: --output-dir /opt/helmfile_render/

Relevant discussion

No response

Operating system

macOS 12.3.1

Helmfile Version

v0.143.4

Helm Version

3.8.1

Bug description

when a defined release is using a template, resolution of needs can fail unless kubeContext is defined explicitly in the release. For example, given this helmfile below I receive the following error:

❯ helmfile -e stage -l app=cert-manager diff --skip-deps
in ./helmfile.yaml: release(s) "cert-manager/letsencrypt-setup" depend(s) on an undefined release "my_kubeconfig_name/cert-manager/cert-manager". Perhaps you made a typo in "needs" or forgot defining a release named "cert-manager" with appropriate "namespace" and "kubeContext"?

environments:
  stage:
    kubeContext: my_kubeconfig_name
    values:
    - environments/default/default.yml
    - environments/stage/stage.yml

templates:
  default: &default
    missingFileHandler: Warn
    namespace: "{{`{{ .Release.Name }}`}}"
    values:
      - "./environments/default/{{`{{ .Release.Name }}`}}.values.yml"
      - "./environments/{{`{{ .Environment.Name }}`}}/{{`{{ .Release.Name }}`}}.values.yml"
      - "./environments/default/{{`{{ .Release.Name }}`}}.values.yml.gotmpl"
      - "./environments/{{`{{ .Environment.Name }}`}}/{{`{{ .Release.Name }}`}}.values.yml.gotmpl"
    labels:
      app: "{{`{{ .Release.Name }}`}}"

- name: letsencrypt-setup
  <<: *default
  needs:
  - "{{.Values.kubeContext}}/cert-manager/cert-manager"
  namespace: cert-manager
  chart: org/letsencrypt-setup
  version: 1.0.0
  installed: {{.Values.LetsEncryptSetup}}
  values:
  - environments/default/letsencrypt-setup.values.yml
  - environments/{{ .Environment.Name }}/letsencrypt-setup.values.yml
  - gcpCredentials: {{.Values.externalDnsServiceAccountKey | fetchSecretValue | quote}}

- name: cert-manager
  <<: *default
  chart: jetstack/cert-manager
  version: v1.7.2
  installed: {{.Values.CertManager}}

however, if I add the field kubeContext to the release, it works:

- name: cert-manager
  <<: *default
  chart: jetstack/cert-manager
  version: v1.7.2
  installed: {{.Values.CertManager}}
  kubeContext: my_kubeconfig_name

Steps to reproduce

see description

Relevant discussion

No response

Operating system

MacOS

Helmfile Version

v0.145.2

Helm Version

v3.9.0

Bug description

Steps to reproduce

• Define an OCI repository in your helmfile
• Define a release that includes a valid reference to an OCI managed chart; but do not specify a namespace in the release defintion
• Run helmfile --namespace my-namespace sync or helmfile --namespace my-namespace template

Expected behaviour

• OCI chart is resolved and sync'd/templated

Actual

• Error thrown by helm Error: failed to download "my-oci-repo/my-chart" at version "1.0.2"

Some analysis

This error does not occur if

• you do not specify --namespace my-namespace arg to helmfile, or
• you specify releases[x].namespace in your helmfile

In the working state, we see the call to helm includes a reference to the temporary folder containing the OCI downloaded chart. In the broken state we see the chart reference as is (i.e. my-oci-repo/my-chart)

Looking at the code, it seems that namespace and kube context overrides are not being considered when looking up the local/temporarily downloaded.

Workaround

Specify a namespace: {{ .Namespace }} attribute in the release definitions in helmfile.yaml

I will attach a sample PR that highlights the problematic lookup.

Example helmfile.yaml

# helmfile.yaml
repositories:
  - name: my-oci-repo
    url: my-ocirepo.com/charts
    oci: true

releases:
  - name: my-release
    chart: my-oci-repo/my-chart
    version: 1.0.2
    # Note "namespace" not included here.  If we were to add "namespace: {{ .Namespace }}" this works fine.

Run with helmfile --namespace my-namespace template

Error message you've seen (if any)

OCI downloader successfully doing it's thing...

Pulling my-oci-repo/charts/my-chart:1.0.2
Exporting my-oci-repo/charts/my-chart:1.0.2
Pulled: my-oci-repo/charts/my-chart:1.0.2
Digest: sha256:d6cfc9e3f18eb18191132c68515dcc490945a6f19b0b83d12c13a377103e043b

Exporting my-oci-repo/charts/my-chart:1.0.2
Pulled: my-oci-repo/charts/my-chart:1.0.2

-- SNIP ---

Helm barfing...

ARGS:
  0: helm (4 bytes)
  1: template (8 bytes)
  2: my-release (14 bytes)
  3: my-oci-repo/my-chart (26 bytes)
  4: --version (9 bytes)
  5: 1.0.2 (13 bytes)
  6: --namespace (11 bytes)
  7: my-namespace (20 bytes)
  8: --values (8 bytes)
  9: /var/folders/wd/nf72qyt51c99_kyl2lb7vcsc0000gp/T/helmfile338136752/my-namespace-my-release-values-7468884646 (120 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  Error: failed to download "my-oci-repo/my-chart" at version "1.0.2"

Steps to reproduce

See above

Working Helmfile Version

N/A

Relevant discussion

No response

Operating system

macOs 12.5

Helmfile Version

0.145.2

Helm Version

v3.8.2

Bug description

Some of the adaptations for OCI charts are dead and / or never used. Finally, the helm pull is executed 2 times for each OCI release and the first one is never used.

Example helmfile.yaml

repositories:
  - name: jycamier
    url: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app
    oci: true

releases:
  - name: app-test
    chart: jycamier/oci-chart-test
    version: 0.1.0
    kubeContext: docker-desktop
    namespace: foo

Error message you've seen (if any)

processing file "helmfile.yaml" in directory "."
changing working directory to "/Users/jycamier/workspace/helmfile"
first-pass rendering starting for "helmfile.yaml.part.0": inherited=&{default map[] map[]}, overrode=<nil>
first-pass uses: &{default map[] map[]}
first-pass rendering output of "helmfile.yaml.part.0":
 0: helmBinary: helm3
 1:
 2: repositories:
 3:   - name: jycamier
 4:     url: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app
 5:     oci: true
 6:
 7: releases:
 8:   - name: app-test
 9:     chart: jycamier/oci-chart-test
10:     version: 0.1.0
11:     kubeContext: docker-desktop
12:     namespace: foo
13:

first-pass produced: &{default map[] map[]}
first-pass rendering result of "helmfile.yaml.part.0": {default map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
 0: helmBinary: helm3
 1:
 2: repositories:
 3:   - name: jycamier
 4:     url: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app
 5:     oci: true
 6:
 7: releases:
 8:   - name: app-test
 9:     chart: jycamier/oci-chart-test
10:     version: 0.1.0
11:     kubeContext: docker-desktop
12:     namespace: foo
13:

merged environment: &{default map[] map[]}
helm3:cQdJs> v3.8.2+g6e3701e
Pulling ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
Exporting ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
exec: helm3 fetch oci://ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test --version 0.1.0 --destination /var/folders/5v/265n35390714j6sjsblgd0cw0000gp/T/chart1120348678
helm3:IdBJm> Pulled: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
Digest: sha256:168c538610c939026932266b9d9f6d66e944e85e1a0cf097d5431dc007206de5
Pulled: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
Digest: sha256:168c538610c939026932266b9d9f6d66e944e85e1a0cf097d5431dc007206de5

Exporting ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
exec: helm3 pull oci://ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test --version 0.1.0 --untar --destination /var/folders/5v/265n35390714j6sjsblgd0cw0000gp/T/helmfile2513451292/foo/docker-desktop/app-test/oci-chart-test/0.1.0
helm3:kazun> Pulled: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
Digest: sha256:168c538610c939026932266b9d9f6d66e944e85e1a0cf097d5431dc007206de5
Pulled: ghcr.io/jycamier/renovate-helmfile-oci-reproduction-app/oci-chart-test:0.1.0
Digest: sha256:168c538610c939026932266b9d9f6d66e944e85e1a0cf097d5431dc007206de5

changing working directory back to "/Users/jycamier/workspace/helmfile"

Steps to reproduce

https://github.com/jycamier/renovate-helmfile-oci-reproduction

Working Helmfile Version

none

Relevant discussion

No response

Operating system

Ubuntu 22.04 LTS

Helmfile Version

0.145.3

Helm Version

v3.8.0

Bug description

Installed microk8s (as snap), enabled helm3.
When running helmfile, it can not find helm binary (in microk8s it is supposed to be run using "microk8s helm3").
If specifying binary explicitly, other error pops up:

helmfile apply -b /snap/bin/microk8s.helm3 --file helmfile.yaml
...
Error: unknown command "diff" for "helm"

Example helmfile.yaml

repositories:

• name: bitnami
  url: https://charts.bitnami.com/bitnami

releases:

• name: redis-padm
  namespace: k8dev
  chart: bitnami/redis
  set:
  • name: primary.persistence.size
    value: 20Gi
  • name: auth.password
    value: "some_pwd462"
  • name: master.persistence.enabled
    value: true
  • name: master.persistence.storageClass
    value: "rook-ceph-block"

Error message you've seen (if any)

Error: unknown command "diff" for "helm"

Steps to reproduce

helmfile apply -b /snap/bin/microk8s.helm3 --file helmfile.yaml

Working Helmfile Version

0.145.3

Relevant discussion

No response

Operating system

macOS 12.4

Helmfile Version

v0.145.2

Helm Version

v3.9.2

Bug description

helmfile now uses helm diff --color introduced in https://github.com/databus23/helm-diff/pull/343/files (helm diff v3.4.0). If one upgrades helmfile using Homebrew but doesn't manually upgrade the helm diff plugin helmfile will fail

Operating system

Arch Linux

Helmfile Version

0.144.0

Helm Version

3.9.0

Bug description

.Values are not available for a local chart.

environments:
  default:
    values:
      - etcd:
          replicaCount: 1
          global:
            storageClass: manual
          persistence:
            storageClass: manual
            size: 4Gi

releases:
  - name: local-chart
    namespace: local
    chart: ./charts/local-chart
    condition: local.enabled
    values:
      - etcd: {{ toYaml .Values.etcd | nindent 10 }}

in ./helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:49:31: executing "stringTemplate" at <.Values.etcd>: map has no entry for key "etcd"

Steps to reproduce

http://here

Relevant discussion

No response

Operating system

Arch Linux

Helmfile Version

0.144.0

Helm Version

3.9.0

Bug description

environments:
  default:
    values:
      - etcd:
          replicaCount: 1
          global:
            storageClass: manual
          persistence:
            enabled: true
            storageClass: manual
            size: 4Gi

releases:
  - name: local-chart
    namespace: local
    chart: ./charts/local-chart
    condition: etcd.persistence.enabled # <--- HERE
    values:
      - etcd: {{ toYaml .Values.etcd | nindent 10 }}

Using etcd.persistence.enabled should be perfectly file. Allowing only a top level value to have enabled is kind of discriminatory.

Steps to reproduce

http://here

Relevant discussion

No response

Operating system

alpine 3.13.10

Helmfile Version

dev

Helm Version

v3.7.2

Bug description

test fixture: https://github.com/itscaro/helmfile/tree/qtran/bug-relative-paths

subhelmfile loader resolves to app1/app1 instead of app1

docker run --rm -ti -v "$(pwd):/source" -w /source quay.io/github/helmfile:dev bash

bash-5.1# helmfile --debug template
processing file "helmfile.yaml" in directory "."
first-pass rendering starting for "helmfile.yaml.part.0": inherited=&{default map[] map[]}, overrode=<nil>
first-pass uses: &{default map[] map[]}
first-pass rendering output of "helmfile.yaml.part.0":
 0: helmfiles:
 1: - app1/helmfile.yaml
 2:

first-pass produced: &{default map[] map[]}
first-pass rendering result of "helmfile.yaml.part.0": {default map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
 0: helmfiles:
 1: - app1/helmfile.yaml
 2:

merged environment: &{default map[] map[]}
processing file "helmfile.yaml" in directory "app1"
changing working directory to "/source/examples/subhelmfiles/app1"
first-pass rendering starting for "helmfile.yaml.part.0": inherited=&{default map[] map[]}, overrode=<nil>
first-pass uses: &{default map[] map[]}
first-pass rendering output of "helmfile.yaml.part.0":
 0: helmfiles:
 1: - path: app.yaml
 2:   values:
 3:   - values1.yaml
 4: - path: app.yaml
 5:   values:
 6:   - values2.yaml
 7:

first-pass produced: &{default map[] map[]}
first-pass rendering result of "helmfile.yaml.part.0": {default map[] map[]}
vals:
map[]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.part.0":
 0: helmfiles:
 1: - path: app.yaml
 2:   values:
 3:   - values1.yaml
 4: - path: app.yaml
 5:   values:
 6:   - values2.yaml
 7:

merged environment: &{default map[] map[]}
processing file "app.yaml" in directory "."
err: environment values file matching "values1.yaml" does not exist in "/source/examples/subhelmfiles/app1/app1"
changing working directory back to "/source/examples/subhelmfiles"
in ./helmfile.yaml: in .helmfiles[0]: in app1/helmfile.yaml: in .helmfiles[0]: in ./app.yaml: environment values file matching "values1.yaml" does not exist in "/source/examples/subhelmfiles/app1/app1"

Steps to reproduce

https://github.com/itscaro/helmfile/tree/qtran/bug-relative-paths

Relevant discussion

No response

Operating system

Ubuntu 20.04

Helmfile Version

0.145.3

Helm Version

3.8.1

Bug description

I want to only render a single template file by using the -s|--show-only flag on helm template. I see that I can pass arbitrary flags to helm template by using helmfile template --args. However, running helmfile template --args and passing the -s flags does not work but the full flag name --show-only does.

Example failing command: helmfile -e dev -l name=foo --skip-needs --skip-deps template --args "-s templates/deployment.yaml"

Example helmfile.yaml

releases:
- name: foo
  namespace: foo
  chart: charts/foo

Error message you've seen (if any)

panic: runtime error: index out of range [1] with length 1

goroutine 1 [running]:
github.com/helmfile/helmfile/pkg/config.NewCLIConfigImpl(0xc000410310)
/home/runner/work/helmfile/helmfile/pkg/config/config.go:18 +0x432
github.com/helmfile/helmfile/cmd.NewTemplateCmd.func1(0xc000819b80?, {0x17178cf?, 0x8?, 0xc?})
/home/runner/work/helmfile/helmfile/cmd/template.go:19 +0x29
github.com/spf13/cobra.(*Command).execute(0xc000819b80, {0xc000308780, 0x8, 0xc})
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:872 +0x694
github.com/spf13/cobra.(*Command).ExecuteC(0xc00088ca00)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:990 +0x3b4
github.com/spf13/cobra.(*Command).Execute(...)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:918
main.main()
/home/runner/work/helmfile/helmfile/main.go:25 +0xbc

Steps to reproduce

N/A

Working Helmfile Version

unknown

Relevant discussion

No response

Operating system

OSX 12.5

Helmfile Version

v0.145.2

Helm Version

v3.9.3

Bug description

When using the Docker image ghcr.io/helmfile/helmfile:v0.145.2 the flag --version doesn't exist and helmfile version doesn't return the version either:

❯ docker run ghcr.io/helmfile/helmfile:v0.145.2 helmfile --version
Incorrect Usage. flag provided but not defined: -version

NAME:
   helmfile

USAGE:
   helmfile [global options] command [command options] [arguments...]

...

❯ docker run ghcr.io/helmfile/helmfile:v0.145.2 helmfile version
helmfile version

Locally the same version works fine:

❯ helmfile --version
helmfile version v0.145.2

❯ helmfile version
helmfile version v0.145.2

Example helmfile.yaml

n/a

Error message you've seen (if any)

❯ docker run ghcr.io/helmfile/helmfile:v0.145.2 helmfile --version
Incorrect Usage. flag provided but not defined: -version

Steps to reproduce

docker run ghcr.io/helmfile/helmfile:v0.145.2 helmfile --version

docker run ghcr.io/helmfile/helmfile:v0.145.2 helmfile version

Working Helmfile Version

n/a

Relevant discussion

No response

Operating system

Ubuntu 22.04 LTS

Helmfile Version

0.145.2

Helm Version

3.9.2

Bug description

When trying to inject a resource into a release it simply ignores.
However, when I add the following to helmfile.yaml it creates the resource:

- name: raw1
  chart: incubator/raw
  values:
  - resources:
    - apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: grafana-selfsigned-ca
        namespace: gloo-system
      spec:
        isCA: false
        commonName: "grafana.sendcloud"
        secretName: grafana-selfsigned-ca
        dnsNames:
        - grafana.sendcloud
        issuerRef:
          name: selfsigned-issuer-ca
          kind: Issuer

Example helmfile.yaml

repositories:
  - name: gloo
    url: https://storage.googleapis.com/solo-public-helm
  - name: jetstack
    url: https://charts.jetstack.io
  - name: prometheus-community 
    url: https://prometheus-community.github.io/helm-charts
  - name: incubator
    url: https://charts.helm.sh/incubator

releases:
- name: gloo-edge
  namespace: gloo-system
  chart: gloo/gloo
  version: '1.12.2'
  needs:
    - cert-manager/cert-manager
  values:
  - resources:
    - apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: grafana-selfsigned-ca
      spec:
        isCA: false
        commonName: "grafana.sendcloud"
        secretName: grafana-selfsigned-ca
        dnsNames:
        - grafana.sendcloud
        issuerRef:
          name: selfsigned-issuer-ca
          kind: Issuer
- name: cert-manager
  namespace: cert-manager
  chart: jetstack/cert-manager
  version: v1.9.1
  set:
  - name: installCRDs
    value: true
- name: kube-prometheus-stack
  namespace: prometheus
  chart: prometheus-community/kube-prometheus-stack
  needs:
    - cert-manager/cert-manager
    - gloo-system/gloo-edge

Error message you've seen (if any)

None, it just doesn't create

Steps to reproduce

helmfile sync

Working Helmfile Version

None

Relevant discussion

No response

Operating system

MacOS 12.4

Helmfile Version

0.145

Helm Version

any

Bug description

v0.145 doesn't seem to be available on quay.io https://quay.io/repository/roboll/helmfile

and the repository https://quay.io/repository/helmfile/helmfile doesn't exist or is not public

Example helmfile.yaml

n/a

Error message you've seen (if any)

n/a

Steps to reproduce

https://quay.io/repository/roboll/helmfile

Relevant discussion

No response

Operating system

Ubuntu:20.04

Helmfile Version

0.145.0

Helm Version

3.9.0

Bug description

When providing selector that has needs: an error is thrown:

Error: flag provided but not defined: -include-needs

Is this not consistently added to all contexts that need it? template, diff and apply work ok with it.

Example helmfile.yaml

releases:

• name: gatekeeper-artifacts
  installed: true
  needs: [gatekeeper]

Error message you've seen (if any)

   helmfile lint - lint charts from state file (helm lint)

USAGE:
   helmfile lint [command options] [arguments...]

OPTIONS:
   --args value         pass args to helm exec
   --set value          additional values to be merged into the command
   --values value       additional value files to be merged into the command
   --concurrency value  maximum number of concurrent downloads of release charts (default: 0)
   --skip-deps          skip running "helm repo update" and "helm dependency build"
2022-07-21T10:04:38.118Z otomi:cmd:lint:lint:error flag provided but not defined: -include-needs
2022-07-21T10:04:38.127Z otomi:global:error Error: flag provided but not defined: -include-needs

Steps to reproduce

lint a release with needs

Working Helmfile Version

0

Relevant discussion

No response

Operating system

None

Helmfile Version

None

Helm Version

None

Bug description

change to github.com/helmfile/helmfile

Steps to reproduce

None

Relevant discussion

No response

Operating system

Windows

Helmfile Version

0.145.2

Helm Version

3.9.0

Bug description

Example helmfile.yaml

no need

Error message you've seen (if any)

no

Steps to reproduce

no need

Relevant discussion

No response

Operating system

Linux

Helmfile Version

none

Helm Version

none

Bug description

cannot install helmfile with correct arch.

Example helmfile.yaml

none

Error message you've seen (if any)

bash: ./helmfile: cannot execute binary file: Exec format error

Steps to reproduce

root@test:/# HELMFILE_VERSION=0.145.0
root@test:/# uname   
Linux
root@test:/# arch
x86_64
root@test:/# wget -qO /helmfile https://github.com/helmfile/helmfile/releases/download/v${HELMFILE_VERSION}/helmfile_${HELMFILE_VERSION}_linux_amd64.tar.gz;
root@test:/# chmod 755 ./helmfile 
root@test:/# ./helmfile 
bash: ./helmfile: cannot execute binary file: Exec format error
root@test:/# rm ./helmfile 
root@test:/# wget -qO /helmfile https://github.com/helmfile/helmfile/releases/download/v${HELMFILE_VERSION}/helmfile_${HELMFILE_VERSION}_linux_386.tar.gz;
root@test:/# chmod 755 ./helmfile 
root@test:/# ./helmfile
bash: ./helmfile: cannot execute binary file: Exec format error

I am trying with HELMFILE_VERSION 0.145.0, but 0.145.* all don't seem to install the correct binaries.

Working Helmfile Version

none

Relevant discussion

No response