Relative path in `environments.*.values` not working in multi-file setup.

[Kellen275]

Operating system

Ubuntu 22.04.2 LTS

Helmfile Version

0.158.1

Helm Version

v3.13.2

Bug description

In my example below, the path to values.yaml specified in base.yaml is relative to the helmfile.yaml, not the base.yaml.

Example helmfile.yaml

Given the following file structure

.
├── base.yaml
├── values.yaml
└── release
    └── helmfile.yaml

With the following file contents helmfile.yaml

bases:
  - ../base.yaml
releases:
  - name: release
    chart: .

base.yaml

environments:
  dev:
    values:
      - values.yaml

values.yaml

foo: bar

Error message you've seen (if any)

$ helmfile lint -e dev -f release/helmfile.yaml
in ./helmfile.yaml: failed to read ../base.yaml: environment values file matching "values.yaml" does not exist in "."

Relevant discussion

https://github.com/helmfile/helmfile/discussions/1301

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[chrisdoherty4]

This looks like expected behavior. The values are relative to the helmfile.yml, not the file being included via bases.

[Kellen275]

Perhaps I'm misinterpreting https://helmfile.readthedocs.io/en/latest/#paths-overview then.

Relative paths referenced in the Helmfile manifest itself are relative to that manifest

Is the following not considered a "Helmfile manifest"?

environments:
  dev:
    values:
      - values.yaml

Is there a recommended way to have Helmfile manifests in different locations include the same base?

It seems like the following structure wouldn't be supported (where both helmfiles attempt to include the base)

.
├── base.yaml
├── values.yaml
├── release
│   └── helmfile.yaml
├── release2
    └── otherdir
        └── helmfile.yaml

[chrisdoherty4]

Is the following not considered a "Helmfile manifest"?

No. The bases get included in the helmfile referenced when you call helmfile. The helmfile is the manifest.

Is there a recommended way to have Helmfile manifests in different locations include the same base?

I didn't design this, but I don't think what you're trying to do is possible. Creating re-usable YAML from 1 independently deployed helmfile to the next isn't possible unless you make your directory structure equivalent or the base doesn't include paths. So in your examplerelease2/helmfile.yml and release/helmfile.yml.

Something you could try is separation of helmfiles from projects. That would remove the need to structure your projects with equivalence on the filesystem.

E.g.

helmfiles/
  environments.yml
  values.yml
  project-a/
    helmfile.yml
  project-b/
    helmfile.yml

---

I think there's a feature request in here somewhere. I too fell into the trap of thinking environments specifically could reference values yaml from the environments files location. Without introducing some sort of togglable mode of operation though, I suspect this would be a breaking change.

[Kellen275]

Thanks for the clarification! My current usage has involved enforcing the same "directory depth" across all my helmfiles as you describe.

It does sound like implementing this would be a breaking change. I'll close this understanding it's intended behavior.