#helmfile (2022-10)

Do you use helmfile value gateway.grpcJsonTranscoder.protoBinContent inside your templates ? State values are helmfile-only values. You may need to use --set to set helm values directly from CLI.

I did that locally and it was ok but in CI system it doesn’t work(have no idea why)

you may check helmfile version in CI

Thanks for help version of the image was canary, but CI system caching images so I used a very old one

It’s weird that you’d be getting different results based on the shell in use. Have you verified that the value of PROTOBIN_ARTIFACT is the same? I’m guessing zsh = local and bash = CI?

If you rule out differences in local vs CI (or similar) one option could be creating a values file on the fly and using --values instead of --set. I’d use dasel (https://github.com/TomWright/dasel) for that as makes it easy to read/write yaml (and many other formats) from the command line.

1. Sure,I’ve checked that I have the same content in both cases
2. Going to check,thanks

@bradym The issue was ARG_MAX on zsh(1048576) and bash(262144) has different values. It depends on OS you are using.

I have multiple releases in one helmfile. Could you prompt how can I pass this “on the fly values file” to a specific release? This is my command currently

helmfile apply . --values=${PROTOBIN_RESULT}

You can use the --selector option on helmfile to limit which releases are considered.

Something like helmfile --selector name=myJob apply

https://helmfile.readthedocs.io/en/latest/#labels-overview

Interesting to know about the ARG_MAX values being different, thanks for the info.

Found this here. Going to try, thank you)

@Georg Grauberger

# helmfile
environments:
  default:
    values:
      - path/to/values.yaml
  local:
    values:
      - path/to/values-local.yaml

releases:
  - chart: some/path/to/local/chart
    name: fooBar
    devel: false
    values:
      # use go template, values come from env config.
      - base.yaml.gotmpl

yes. you can test it.

Thanks for your advice. We will think about it carefully and migrate as smoothly as possible.

We might add an optional v1 mode to helmfile v0.x, while adding a big nosiy warning for a legacy helmfile.yaml. The idea is that you can use both formats for a while, so that you can migrate helmfiles one-by-one. Does that work for you?

Does that work for you? Yes, this will be really good. Thanks

For more details: my pc is Darwin arm64, the values.yaml is empty, find below the content of the Chart.yaml, and the detailed error with –enable-live-output and –debug as well.

#Chart.yaml

apiVersion: v2
name: mychart
version: 1.0.0

Live output is enabled
processing file "helmfile.yaml" in directory "."
changing working directory to "/path/to/home/test"
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: repositories:
 1:   - name: jetstack
 2:     url: <https://charts.jetstack.io>
 3:
 4: releases:
 5:   - name: mychart
 6:     chart: .
 7:     namespace: mychart
 8:     values:
 9:       - ./values.yaml
10:     installed: true
11:     dependencies:
12:       - version: v1.10.0
13:         chart: jetstack/cert-manager
14:

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: repositories:
 1:   - name: jetstack
 2:     url: <https://charts.jetstack.io>
 3:
 4: releases:
 5:   - name: mychart
 6:     chart: .
 7:     namespace: mychart
 8:     values:
 9:       - ./values.yaml
10:     installed: true
11:     dependencies:
12:       - version: v1.10.0
13:         chart: jetstack/cert-manager
14:

merged environment: &{default map[] map[]}
helm:xuSyz> v3.10.1+g9f88ccb
Adding repo jetstack <https://charts.jetstack.io>
exec: helm repo add jetstack <https://charts.jetstack.io> --force-update
"jetstack" has been added to your repositories
Chartify process for .
Successfully generated the value file at values.yaml. produced:

running helm repo list
Removing the dependencies field from the original Chart.yaml.
running helm dependency up /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart
Removing the dependencies field from the original Chart.yaml.
options: {false [/var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/helmfile462959889/mychart-mychart-values-5bdbc4876c] [] [] mychart  true false  [] true}
running helm template --debug=false --output-dir=/var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart/helmx.1.rendered --include-crds mychart /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart -f /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart/values.yaml -f /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/helmfile462959889/mychart-mychart-values-5bdbc4876c --namespace mychart
Removing the dependencies field from the original Chart.yaml.
Removed /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/helmfile462959889/mychart-mychart-values-5bdbc4876c
Updating dependency /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart
exec: helm dependency update /var/folders/3r/_xtmgjd569d_lzyb3cvtmt_r0000gn/T/chartify4103983402/mychart/mychart
There are no repositories defined in your helmfile.yaml.
This means helmfile cannot update your dependencies or create a lock file.
See <https://github.com/roboll/helmfile/issues/878> for more information.

I thought adhoc dependencies had never been included in the helmfile.lock

Are you basically saying that it’s your first time to mess with helmfile.lock, to be clear?

If it worked for previous versions of helmfile, it might be a bug. But if it’s your first trial, it might be that it had never been supported by helmfile

Hi @mumoshu, thanks for your reply. Well, I assume the purpose of a helmfile.lock is the usual one for lock files: locking the dependency modules to achieve reproducible builds. I therefore expected ‘helmfile deps’ to produce a lock file, as ‘helm dep up’ does. I may be wrong, could you elaborate your answer ? And I do not understand why ‘helmfile deps’ is not working anyway (error message + not generating Chart.lock and charts/), stating that no repositories are defined while it is in the helmfile.yaml. Several discussion claims that must be sufficient, as this one stated in the error message itself: https://github.com/roboll/helmfile/issues/878. I created this issue with repos to reproduce the issue: https://github.com/helmfile/helmfile/issues/474

I am running a Darwin arm64, so the earliest version available is 0.143.0 and it does work either. It may be working with earliest version though. When you say that it might be that it had never been supported by helmfile, how a sub-command to helmfile itself i.e. ‘helmfile deps’ could not be supported ? But the helmfile.lock may not be indeed.

It works too with ‘helmfile deps’ when moving the ‘dependencies’ block to Chart.yaml, it builds a Chart.lock and a charts/ folder. And yet, I still get the error message stating that no repositories defined in the helmfile.yaml

Thanks. I thought Helmfile’s own dependency management system only looked to repositories and relelases[].chart, but releases[].dependencies. It’s because releases[].dependencies are handled by an external library called “chartify” and apparently it isn’t integrated to the helmfile’s dependency management system. I do see one thing to be fixed from your report. helmfile.lock should be changed to include dependencies from releases[].dependencies.

However, for Chart.lock, this might be the correct way forward.
moving the ‘dependencies’ block to Chart.yaml, it builds a Chart.lock and a charts/ folder

Hi Mumoshu, sorry for the delay I have been very busy. Thanks for you reply, it helped to understand some things as I expected helmfile to work the same as helm regarding releases[].dependencies. Yes that is normal that the helm dependencies are not included into the helmfile.lock managing the helmfile charts. But I was expected the releases[].dependencies to be included into the helmfile.lock, simillarly to the helm behaviour into the Chart.lock. There is a ‘work-around’ though, which is to include all the dependencies as single helmfile charts and use ‘needs’ to install the charts before your own local chart. In this way you have a fixed version for all dependencies, and you don’t need to create an umbrella chart to put your dependencies into the Chart.yaml or to put the dependencies in the Chart.yaml of your local Chart.yaml. As you suggested, I don’t think that releases[].dependencies have ever been included into the helmfile.lock, which is very confusing and in my view should be, or this feature should be removed (in which case unlocked dependencies would be used ? ) to only allow the ‘work-around’