Unrelated to the above, is it possible to set environment variables in

helmfile.yaml

that can be used by vals references (i.e.

ref+protocol://

), or by templates using

{{ env ... }}

/

{{ requireEnv ... }}

? In my case I have many vals refs to the Pulumi API, and I can either repeat the same 3 query parameters for each ref, or set env vars for them. I'd like to keep this self-contained by not requiring env vars be set when running

helmfile

commands, but I also don't want to repeat the query parameters for each ref. Ideally I could do something like this:

environments:
  default:
    env:
      PULUMI_ORGANIZATION: my-pulumi-org

Hello guys! I might be missing something, can anyone help? 🙂 How can I elegantly avoid a failure for helm chart dependancy installation that fails for it's CRD ownership? For example if I need Prometheus or ExternalSecrets CRDs I add them as a dependancy in the Chart.yaml but their owners are different so I fail. What am I missing? 🙂 Something like this:

Unable to continue with install: CustomResourceDefinition "<http://acraccesstokens.generators.external-secrets.io|acraccesstokens.generators.external-secrets.io>" in namespace "*****" exists and cannot be imported into the current release: invalid ownership metadata;

Is there some clever way to hoist a release as a need of all other releases in the helmfile? Currently I'm manually adding it as a need to every release

Are there any patterns or strategies I can use for a large helmfile to "retry" a failed install? If any single chart fails to install, the entire apply fails and you have to manually re-run it

Are anyone using the hcl values in their stuff? Would be nice to have some example of a real world usage.

Did https://github.com/mamezou-tech/setup-helmfile randomly stop working for anyone?

@mumoshu @yxxhero congrats on reaching V1 milestone! I want to stress importance of https://github.com/helmfile/helmfile/issues/1079, which I believe is a breaking bug for V1. Ideally it must be fixed to ensure smooth transition. Not ideally, but acceptable, is to properly document it in V1 release notes. Otherwise it's a very sneaky bug that will break end user regexes, potentially breaking chart deployments, due to incorrect regexes passed into.

@Ihor Urazov thanks so much. we will solve this issue.

hey hey everyone! I'm struggling a bit with using helmfile when deploying the

opensearch

chart, where I need to set the

javaOpts

to something like

-Xms16g -Xmx16g

. I put such value in each environment yaml (note: we use the value using the

{{ .Environment.Values.openSearchJavaOpts }}

), but when

helmfile

goes to deploy stuff, it translates our configuration as follows:

helm template ... --set opensearchJavaOpts=-Xms16g -Xmx16g

which obviously doesn't work as it interprets the part after the space as a shorthand flag for helm itself. I tried various ways to encode the value, hoping to be able to pass that whole string as a single value but nothing worked, the string is always unquoted during the

helm template

invocation, triggering the issue. Any ideas? Thanks in advance for any suggestion 🙇 disclaimer: we are using

forceNamespace: true

as without it everything is deployed on the

default

namespace, which we don't want

Here attached some great resource for linux and kubernetes. https://github.com/Pulkit12966/redhat_official_studyguide_RHCSA

Hi, I'm trying to understand how i can deploy different versions of charts to different environments. For instance, I want to have a qa environment use a newer version of a chart for testing compatibility ahead of rolling the chart to a prod environment. I've tried a few approaches, but i'm stuck trying to work it out. The most sensible sounding approach (generated by AI i think) was; https://gurubase.io/g/helmfile/different-chart-versions-helmfile-environments where i pop;

releases:
  - name: myapp
    chart: stable/mychart
    version: {{ .Environment.Values.mychart.chartVersion }}

but every time i try and run

helmfile build qa

i get an error;

in ./helmfile.yaml: error during helmfile.yaml.part.1 parsing: template: stringTemplate2029: executing "stringTemplate" at <.Environment.Values.mychart.chartVersion>: map has no entry for key "mychart"

Has anyone got any suggestions on how to deal with per-env chart versioning?

I'm trying to get rid of all CustomResourceDefinition resources from helmfile template via patches. I think it should be possible with '$patch: delete' and a regex selector for the name of the CRD but helmfile errors out with a message that no resources can be found. If I use an exact name, it works. I'm using this patch:

strategicMergePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      name: .*
    $patch: delete

Does helmfile work differently and does it not support regex matches on the name? If so, how do I target multiple resources with some kind of wildcard? I'm basing this on https://github.com/kubernetes-sigs/kustomize/blob/master/examples/patchMultipleObjects.md Also, it seems that name is somehow mandatory when using it with Helmfile but from the above link it seems that name is optional?

Maybe I should focus more on Kustomize itself. It seems that a name is required but regex matching doesn't work for some reason.

Hi everyone ! I recently had to fiddle with implementing the Scaleway provider for vals, here is a (very crude) first draft : https://github.com/Xide/vals/tree/feat/scaleway-secret-manager I was wondering if you were open to the addition of this new provider upstream. If so, i think i can open the PR by the end of week (need some time to implement test & docs). Thanks

hey, is it possible to apply a normal manifest as a resource in helmfile? specific usecase is pre-applying CRDs from manifests (typically URLs, like GatewayAPI CRDs) before all other releases

Hi, I am new to use helmfile. Does anyone know how to config the helmfile so that when I rebuild my chart image, my app will be restarted and pull the latest image? P.S: the image tag will not be changed when the image is rebuilt or if I can redeploy one single app in the same release without tearing down all apps and the restart all apps?

Hello, I've started looking at Helmfile for work (and am pretty excited TBH). Should I consider Helmfile to be API stable? The current version is v1.1.2, the status section suggests that the project adheres to SemVer, and I've read: https://github.com/helmfile/helmfile/blob/main/docs/proposals/towards-1.0.md However, the most recent item on the status page is 2022, and I have not found a canonical statement elsewhere that v1.1 is API-stable. https://helmfile.readthedocs.io/en/stable/#status This may seem a little fussy, but I will be challenged on this point if I propose that my company adopts Helmfile.

im not sure if i understand this well... 1. I have a mono repo. 2. when i push to master, gh workflow build and push my docker to ghcr, and update the helmfile's environment config with the appropriate tag now what? how do i do the cd/deployment? argocd? how does argocd integrates?

when you push to master, your workflow builds and pushes a docker image to ghcr and updates your helmfile config with the new image tag. that’s the "ci" part done. now for "cd" this is where something like argo cd fits in. argo cd is a gitops based continuous deployment tool that keeps your cluster in sync with your git repo. you would typically store your helmfile in a separate gitops repo or a deployment folder in your mono repo. argo cd watches that repo (or subfolder) for changes. so, when your ci workflow updates the helmfile with the new image tag and pushes that change, argo cd detects it and automatically applies the update to your cluster. in short, argo cd integrates by continuously monitoring your git repo and sync it to the actual state of the cluster. you define what "should be running" in git, and argo makes sure the cluster reflects that.

thanks I told claude to implement using this. i hope itll work, lol https://christianhuth.de/deploying-helm-charts-using-argocd-and-helmfile/

not sure how to handle the sops thingy now :W

Can I have references like this pseudo code in my environment file?

temporal:
  address: temporal.svc.addr
  api_key: 1234

my_server:
   temporal_addr: $temporal.address

Hey all! I’m trying to setup a gitops solution based on helm. All of my yamls are in a monorepo, and I'm not building any charts manually using

helm dependency build

or any other helm command. In my solution I will need nested dependencies to be resolved automatically, as I want several layers of values (with overrides for each layer) For example:

/clusters/01/Chart.yaml

will have a dependency of

/environments/prod

/environments/prod/Chart.yaml

will have a dependency of

/region/US

/region/US/Chart.yaml

will depend on an "umbrella" chart, that this umbrella chart will deploy all apps, while overriding the values according to the precedence of the dependencies. Using helm in Flux/ArgoCD, I was not able to do that as helm doesn't support recursive dependency building, so only the first 2 charts were deployed. I tried using basic helmfile examples, but the same limitation still in place. I wonder if I can somehow leverage helmfile to dynamically resolve all nested dependencies of an helm chart without having to commit all charts'

tgz

files?

Hello All, I am new to

helmfile

and I realised that it's really a great tool. But I am facing a problem: I am unable to connect to private git repository using the private access token. I suspect I am using wrong format for the repository url. Can someone please advise how can I do that? Preferably with some code example.

Has anyone found a way to destroy/terminate namespaces created by the Terraform resource kubernetes_namespace when they get stuck in the Terminating state? Right now, the only thing that seems to work is manually clearing the finalizers, like this:

kubectl get ns "$ns" -o json | jq 'del(.spec.finalizers)' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -

Just wondering if anyone's found a cleaner or automated way to handle this by terraform ?

Hi. I tried to add a

strategicMergePatches

to a release that uses a Helm chart containing the Helm

lookup

function. It seems once kustomize comes into play, the

lookup

function no longer executes.

Been thinking about this for a bit but am looking for a sanity check / other ideas. I use vals lookups (i.e. ref syntax) with the s3 terraform state backend. I'm going to refactor terraform and clean up the s3 state paths which are pretty gnarly at present, but the vals backend doesn't support multiple s3 object keys or fallback behavior. Similarly if a vals lookup fails it causes templating to fail instead of rendering to null or an empty string (probably a desirable behavior). I'd like to avoid littering my templates values files with lots of conditionals to inform one of two vals lookups (old path and new path). Is there any helmfile and/or vals feature I'm missing that would help me with transition while I'm refactoring terraform state object paths?

Hi, I am trying to source my helmfiles from an Artifactory remote

helmfiles:
  - path: https://{{ env ("ARTIFACTORY_AUTH") }}@{{ .Values.helmChartRepo.host }}/artifactory/helm-local/pgadmin-helmfile-{{ .Values.helmfile.version }}.tgz?archive=tgz

However, it seems that this approach does not automatically unarchive the .tgz file? If I check the cache path the file is downloaded, but not unarchived. So then the

helmfile template

fails with:

no top-level config keys are found in pgadmin-helmfile-1.0.0.tgz

Does anyone have experience on how to do this? Using helmfile version 1.4.4

Hey All, after upgrading to the latest helmfile from v0.163.0 I am seeing the following error as helmfile attempts to decrypt secrets files with sops loaded from my environments.yaml:

$ helmfile -e mgmt-eng diff
Decrypting secret /home/user/.workspaces/z/argoCD-factory-ops/secrets/mgmt-eng/argocd.yaml
Decrypting secret /home/user/.workspaces/z/argoCD-factory-ops/secrets/mgmt-eng/secret1484928982.yaml
command "/usr/local/bin/helm" exited with non-zero status:

PATH:
  /usr/local/bin/helm

ARGS:
  0: helm (4 bytes)
  1: secrets (7 bytes)
  2: decrypt (7 bytes)
  3: /home/user/.workspaces/z/argoCD-factory-ops/secrets/mgmt-eng/secret1484928982.yaml (94 bytes)

ERROR:
  exit status 1

EXIT STATUS
  1

STDERR:
  [helm-secrets] File does not exist: /home/user/.workspaces/z/argoCD-factory-ops/secrets/mgmt-eng/secret1484928982.yaml
  Error: plugin "secrets" exited with error

COMBINED OUTPUT:
  [helm-secrets] File does not exist: /home/user/.workspaces/z/argoCD-factory-ops/secrets/mgmt-eng/secret1484928982.yaml
  Error: plugin "secrets" exited with error

I have the latest version of sops, helm-secrets, and helm 3.x installed. Is this a known issue? I have tried renaming the secrets file to end in

.gotmpl

with no success. I've searched github and this slack but don't see anyone talking about it. The decryption seems to be working but then helm-secrets apparently can't find the file?

hi I am using helmfile to manage the chart release, and it's awesome Can u give me some suggestions to manage raw manifest? Here is my case, after I install kyverno, I need to apply some policy using manifest I can apply them by kubectl apply -f manifest.yaml I wonder is there any better solution like how helmfile manage release