* fix: prevent preparing chart for disabled releases
Previously, PrepareCharts does not filter any releases whose condition
is disabled with no selectors.
Prevent following things from
- using any unnecessary computing resources for disabled charts
- throwing any error from wrong configurations for disabled charts
Signed-off-by: Seonghoi lee <mighty1231@gmail.com>
* fix: working for integration test about list and build
Some tests require that PrepareCharts without any selector
may not add any labels on the release.
make markExcludedReleases do not add any label without any selectors
Signed-off-by: Seonghoi lee <mighty1231@gmail.com>
* fix: prevent resolved chart version loss
State loss the resolved chart version info from st.Releases
when st.GetSelectedReleases() be called
update st.Releases after st.GetSelectedReleases() in prepareCharts
Signed-off-by: Seonghoi lee <mighty1231@gmail.com>
* fix: preserve resolved version from resolveDeps
In PrepareCharts, the version, resolved from resolveDeps,
is removed after invoking GetSelectedReleases.
Do updateDeps at the first before GetSelectedReleases call
Signed-off-by: Seonghoi lee <mighty1231@gmail.com>
---------
Signed-off-by: Seonghoi lee <mighty1231@gmail.com>
* Resolve dependencies before releases are created
Signed-off-by: vlpav030 <vpav.030@gmail.com>
* Add test
Signed-off-by: vlpav030 <vpav.030@gmail.com>
---------
Signed-off-by: vlpav030 <vpav.030@gmail.com>
* Add "PostRendererArgs" option to be passed to helm
This allows using PowerShell scripts on Windows as Post Renderer.
Signed-off-by: Maarten Boekhold <maarten.boekhold@finastra.com>
This should fix#435 for Helmfile v0.x releases since the next v0.150.0.
We introduce a new envvar to opt-in to the new YAML library, so that you can give it a shot before upgrading your Helmfile to v1. The same envvar can be used to opt-out of the new YAML library after you upgrade to Helmfile v1, giving you a more flexible migration story.
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
* fix env value lost in environment values
Signed-off-by: yxxhero <aiopsclub@163.com>
* add more test
Signed-off-by: yxxhero <aiopsclub@163.com>
Signed-off-by: yxxhero <aiopsclub@163.com>
This is a successor to #596. We need a smooth migration path from `gopkg.in/yaml.v2`, and this pull request moves it forward with `goccy/go-yaml` instead of `gopkg.in/yaml.v3`. Merging this unblocks users stuck in Helmfile v0.146.x or earlier due to #435, so that they can upgrade to 0.147.x or greater without updating their helmfile configs.
We previously tried to upgrade to `yaml.v3` (https://github.com/helmfile/helmfile/issues/394) in Helmfile v0.x, presuming it won't break anything. Apparently, it broke use-cases where you want to layer release's `values` field over three or more release templates and releases (#435).
We then tried to bring back `yaml.v2` for Helmfile v0.x and keep `yaml.v3` for the upcoming Helmfile v1. However, it failed due to incompatibility in the Unmarshaller interface between `yaml.v2` and `yaml.v3` (https://github.com/helmfile/helmfile/pull/596).
`goccy/go-yaml` is, from my observation, a well-maintained alternative to `yaml.v2`. One of its premises is that it enables us to swap the implementation from `gopkg.in/yaml.v2` to `goccy/go-yaml` just by replacing the import directive. It seems to use the same `Unmarshaller` interface as yaml.v2 too.
Once this PR gets merged, I'd like to follow-up with adding a new build-time variable and an envvar to set the proper default for the yaml parser Helmfile uses and the ability to switch the parser at runtime. All in all, the next Helmfile release, v0.150.0 will get reverted to use `gopkg.in/yaml.v2` by default which resolves#435.
New users who started using Helmfile since any of v0.148.0, v0.148.1, and v0.149.0 might be already relying on the new behavior, They might need to specify a new envvar to enable `goccy/go-yaml`.
Signed-off-by: yxxhero <aiopsclub@163.com>
Signed-off-by: yxxhero <aiopsclub@163.com>
Co-authored-by: yxxhero <aiopsclub@163.com>