Merge remote helmfile with local values

[XenoAura]

It would be nice if the following syntax was implemented. Remote helmfile and local values are not currently being merged.

helmfiles:
  - path: git::ssh://git@dsf.yaml
    values:
      - values.yaml

Originally posted by @kamsz in #469 (comment)

[andrewnazarov]

I don't think I'm following you correctly but we've been using this syntax for some time. It works for us.

[XenoAura]

I discovered strange behavior.
This works for repositories in github, but not working for gitlab repos. (not correct)

upd.

Reproducing the problem

helmfile.yaml

helmfiles:
- path: git::https://github.com/XenoAura/helmfile-test.git@helmfile.yaml?ref=master
  values:
    - metallb-vals.yaml

metallb-vals.yaml

configInline:
  address-pools:
    - name: ingress
      protocol: layer2
      addresses:
      - 10.12.12.184-10.12.12.184

prometheus:
  serviceMonitor:
    enabled: false
  prometheusRule:
    enabled: false

$ helmfile --log-level debug template

instead of values from metallb-vals.yaml i saw following log:

worker 1/1 finished
successfully generated the value file at values.yaml. produced:
configInline: {}

prometheus:
  serviceMonitor:
    enabled: true
  prometheusRule:
    enabled: true

another repo: https://gitlab.com/XenoAura/helmfile-test.git@helmfile.yaml?ref=master

[andrewnazarov]

We are using Gitlab:)

Probably our case is a bit different as we are utilizing environments:. But since global environments are not inherited by sub-helmfiles we've ended up with the following workaround:

environments:
  staging:
    values:
      - environments/staging.yaml

helmfiles:
  - path: git::https://gitlab+mytoken:{{ requiredEnv "REPO_TOKEN" }}@gitlab.mydomain.com/my-project/my-repo.git@deployment/helmfile.yaml?ref=master
    values:
      - environments/staging.yaml

and we run this like helmfile -e staging diff

[baurmatt]

Running into the same problem. Using the syntax shown in the README.md doesn't use the provided values file:

...
helmfiles:
- path: path/to/subhelmfile.yaml
  values:
    # Values files merged into the nested state's values
    - additional.values.yaml
...

Also your workaround @andrewnazarov doesn't work for us:

environments:
  default:
    values:
      - values.yaml

helmfiles:
  - path: git::https://gitlab.com/path/to/project@helmfile.yaml?ref=master
    values:
      - values.yaml

[andrewnazarov]

@baurmatt what is your helmfile version?

[baurmatt]

@andrewnazarov v0.114.0

[baurmatt]

I think the problem is: You can't override values which are defined in other values YAML includes.

For example this doesn't work:

helmfile-to-be-included.yaml

...
releases:
  - name: foo
    ...
    values:
      - values.yaml # Uses replica: 1
...

helmfile.yaml:

helmfiles:
  - path: path/to/helmfile-to-be-included.yaml
    values:
      - values-override.yaml # Uses replica: 2

But this seems to work:

helmfile-to-be-included.yaml

...
releases:
  - name: foo
    ...
    values:
      - replica: 1
...

helmfile.yaml:

helmfiles:
  - path: path/to/helmfile-to-be-included.yaml
    values:
      - values-override.yaml # Uses replica: 2

[andrewnazarov]

Yes, our case is your second example. We don't have these nested references. In our remote helmfile we have inline values only.

[baurmatt]

Thanks for checking! :) Sadly this approach doesn't work for us, as we depend on two different files of values being used in the sub helmfile:

...
releases:
  - name: prometheus-operator
    chart: stable/prometheus-operator
    version: 8.12.3
    values:
      - values-managed-services.yaml
      - values-base.yaml
...

This is because the values-base.yaml gets used by another project.

[abdennour]

I am using submodules to overcome this issue.