After ApplyOverrides/reformat(), need IDs are already fully-qualified
(matching ReleaseToID format). The nameToID map was doing redundant
name-based lookups that could theoretically select the wrong dependency
when multiple releases share the same name across namespaces (same issue
fixed in collectDirectNeedsOnly in 02a5de3). Reverted to the original
behavior of passing need IDs as-is.
Co-authored-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/7b896c61-ba38-4471-942a-784e79fab298
- In withNeeds second withDAG call, set SkipNeeds when needs are already
included (instead of using IncludeNeeds which causes DAG to pull in
transitive deps). This is the key fix for --include-needs only including
direct dependencies.
- In GroupReleasesByDependency, use WithDependencies from opts.IncludeNeeds
only when SelectedReleases is explicitly provided (withDAG path).
When using the Filtered flag path, needs are already handled by
markExcludedReleases.
- Regenerate test snapshots to reflect correct behavior where
--include-needs excludes transitive dependencies.
- Restore diff_test.go and diff_nokubectx_test.go from main for
non-include-needs test cases.
Co-authored-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/170cecc0-7a3e-4326-98d3-4f2bffee1848
The root cause of the CI failure was that GroupReleasesByDependency was changed
to use !r.Filtered instead of opts.SelectedReleases for the DAG plan's Only field.
When no selectors are active (like helmfile destroy), all releases are unfiltered,
causing all releases to be planned for deletion - including uninstalled ones.
Fix: Use opts.SelectedReleases when provided, fall back to Filtered flag otherwise.
Also remove unnecessary SelectedReleases block from PlanReleases since
GroupReleasesByDependency now handles it directly.
Restore test snapshots from main as the behavior should now match.
Co-authored-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/170cecc0-7a3e-4326-98d3-4f2bffee1848
- Fix collectDirectNeedsOnly to correctly match needs by full ID
- Fix PlanReleases to respect SelectedReleases when provided
- Fix unmarkNeedsDirectOnly to use full release IDs
- Update tests to expect correct behavior for include-needs vs include-transitive-needs
- Add SkipNeeds flag when needs are pre-included in withNeeds
This fixes CI issues in PR #2485
Signed-off-by: yxxhero <aiopsclub@163.com>
Fixes#1003
Previously, --include-needs was incorrectly including transitive
dependencies (dependencies of dependencies). This fix ensures that:
- --include-needs only includes direct needs
- --include-transitive-needs includes both direct and transitive needs
Changes:
- Add separate handling for direct vs transitive needs in state.go
- Add IncludeNeeds field to ChartPrepareOptions
- Add unmarkNeedsDirectOnly() and collectDirectNeedsOnly() functions
- Update ForEachState and related functions to accept both flags
- Fix incorrect usage of c.IncludeNeeds() for IncludeTransitiveNeeds
- Update tests to verify the correct behavior
Signed-off-by: yxxhero <aiopsclub@163.com>
* Do fail on a possible typo in `needs` entries
Helmfile kindly fails with a friendly error when you made a typo in a `needs` entry, i.e. a `needs` entry included a reference to a release that is not defined in the helmfile config.
Example Output:
```
in ./helmfile.needs.yaml: release(s) "app" depend(s) on an undefined release "infrastructure/cert-manager2". Perhaps you made a typo in `needs` or forgot defining a release named "cert-manager2" with appropriate `namespace` and `kubeContext`?
```
This prevents issues like #1959
* Fix regression in helmfile-diff (This may break when you had two or more duplicated releases that are intended to be de-duplicated before DAG calculation using selectors
* Fix regression when you used selector to deduplicate releases before DAG calculation
* Comments
* Fix regressions in helmfile-apply and helmfile-sync
* Fix regression in duplicate release detection
#1772 broke `--selector` with `needs` in many ways.
The two biggest problems I've encountered were:
- duplicate releases even if you've provided a proper `selector` to deduplicate
- sync/deletion ordering broken when you have `needs`
For the first issue, we had to update `getSelectedReleases` function to also calculate the "selected releases and releases needed by the selected releases", and use that to calculate the DAG. That should have been done in #1772.
The latter started happening after I've fixed the first issue. The source of the issue was that `needs` turned out to be ambiguous in a few cases.
Previously, `needs: ["foo/bar"]` had two meanings. One for "needs release bar in kubecontext foo", another for "needs release bar in namespace foo".
Moreover, `needs: ["foo/bar/baz"]` had three meanings.
- `needs release baz in tiller namespace foo and namespace baz`
- `needs release baz in namespace bar in kubecontext foo`
- `needs release baz in tiller namespace bar in kubecontext foo`.
Especially, the first meaning doesn't make sense at all. Helm 2 solely use tillerNamespace for namespacing the release and Helm 3 uses namespace for that.
This fix sorts all the bugs and issues I've found so far around that, by changing the meanings of the above two examples as follows:
- `foo/bar` means `namespace=foo,name=bar` for Helm 3 and `tillerNamespace=foo,name=bar` for Helm 2
- `needs release bar in kubecontext foo` is now `foo//bar`. Notice the extra `/` between `foo` and `bar`.
- `foo/bar/baz` means `kubecontext=foo,namespace=bar,name=baz` for Helm 3 and `kubecontext=foo,tillerNamespace=bar,name=baz` in Helm 2
Fixes#1818
* Add --{include,skip}-needs to helmfile-sync and helmfile-apply
* Add --include-needs to helmfile-template
* Add TODO related to #1018
* Add a few new test files to cover new functionalities
* Update apply test to incorporate the change that the destroy and sync steps target affected releases only
This is the GA version of the helm-x integration #673 developed last year.
You get all the following benefits without an extra helm plugin:
- Ability to add ad-hoc chart dependencies/aliases, without forking the chart (Fixes#876 )
- Ability to patch resulting K8s resources before installing the helm chart
- Ability to install a kustomization as a chart (Requires `kustomize` binary to be available in `$PATH`
- Ability to install a directory of K8s manifests as a chart
- etc.
The problem was that `--namespace NS` had been not taken into account while deleting releases, that resulted in releases that should be deleted are not deleted.
* fix: Fix `needs` to work for upgrades and when selectors are provided
Fixes#919
* Add test framework for `helmfile apply`
* Various enhancements and fixes to the DAG support
- Make the order of upgrades/deletes more deterministic for testability
- Fix the test framework so that we can validate log outputs and errors
- Add more test cases for `helmfile apply`, along with bug fixes.
- Make sure it fails with an intuitive error when you have non-existent releases referenced from witin "needs"
Introduces DAG-aware installation/deletion ordering to Helmfile.
`needs` controls the order of the installation/deletion of the release:
```yaml
relesaes:
- name: somerelease
needs:
- [TILLER_NAMESPACE/][NAMESPACE/]anotherelease
```
All the releases listed under `needs` are installed before(or deleted after) the release itself.
For the following example, `helmfile [sync|apply]` installs releases in this order:
1. logging
2. servicemesh
3. myapp1 and myapp2
```yaml
- name: myapp1
chart: charts/myapp
needs:
- servicemesh
- logging
- name: myapp2
chart: charts/myapp
needs:
- servicemesh
- logging
- name: servicemesh
chart: charts/istio
needs:
- logging
- name: logging
chart: charts/fluentd
```
Note that all the releases in a same group is installed concurrently. That is, myapp1 and myapp2 are installed concurrently.
On `helmdile [delete|destroy]`, deleations happen in the reverse order.
That is, `myapp1` and `myapp2` are deleted first, then `servicemesh`, and finally `logging`.
Resolves#715