You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The more we add options to helmDefaults the more the name sounds odd to me.
To me, it's basically releaseDefaults, because helmfile uses everything defined under helmDefaults as the default values for per-release settings. But releaseDefaults sounds a bit verbose, and I don't have specific reason not to make it as simple as defaults.
Thoughts?
The text was updated successfully, but these errors were encountered:
releaseDefaults may actually be more intuitive as it makes clear that you can't set defaults for other top-level helmfile settings like environments and repositories.
I liked the idea of helmDefaultas being the helm commandline arguments to be used.
I am fine with releaseDefaults but does that mean the we will be able to set commong "values" for releases in this items ?
If yes, how will it play with the environments values ?
I am fine with releaseDefaults but does that mean the we will be able to set commong "values" for releases in this items ?
Possibly yes.
how will it play with the environments values ?
As the same as how it works today. For example, {{ .Environment.Name }} within a values entry of releaseDefaults will be replaced with the environment name on helmfile.yaml load.
{{` {{.Release.Name}} `}}
for example will be replaced with the name of the each release being processed.
The more we add options to
helmDefaults
the more the name sounds odd to me.To me, it's basically
releaseDefaults
, because helmfile uses everything defined underhelmDefaults
as the default values for per-release settings. ButreleaseDefaults
sounds a bit verbose, and I don't have specific reason not to make it as simple asdefaults
.Thoughts?
The text was updated successfully, but these errors were encountered: