Relative path in `environments.*.values` not working in multi-file setup.
Closed this issue · 12 comments
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
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.
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.
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.
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.
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.
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.
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.
This looks like expected behavior. The values are relative to the helmfile.yml
, not the file being included via bases
.
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
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.
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.
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.
@yxxhero ^ we should update our docs and examples to show this type of usage: that way individuals seeking help in this area have a way forward