When a release with 'installed: false' appears multiple times in the release list
(due to duplicate entries or being included via needs), the isReleaseInstalled
function was being called multiple times for the same release, resulting in
duplicate 'Listing releases' log messages.
This fix adds a deduplication check using a 'checked' map to ensure each release
is only checked once, preventing duplicate helm list calls and log messages.
This fixes the diff-args integration test where 'Listing releases matching
^uninstalled$' appeared twice in stderr output.
Signed-off-by: yxxhero <aiopsclub@163.com>
When running helmfile diff with releases that have 'installed: false',
(flagging them as to-be-uninstalled), the release was being disabled
flag would be included in toRender. Later, these disabled releases were
added again via releasesToUninstall when includeDisabled is true,
causing them to appear twice in the final releases list.
This resulted in duplicate 'Listing releases' log messages and
potentially duplicate helm list calls.
The fix filters out disabled releases from toRender before passing it
to withDAG. This ensures disabled releases are only included once
in the final list (via releasesToUninstall at line 2378-2382).
Fixes the test failure in test/integration/test-cases/diff-args
where 'Listing releases matching ^uninstalled$' appeared twice
instead of once.
Note: diff-live-stderr still shows two messages because that test
was updated separately to match that behavior (with trailing spaces).
The non-live diff should now correctly shows only one message.
Signed-off-by: yxxhero <aiopsclub@163.com>
- 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>
The withNeeds function was calling getSelectedReleases with false, false
for includeNeeds and includeTransitiveNeeds, which caused it to ignore
the --include-needs and --include-transitive-needs flags.
This fix:
1. Computes includeNeeds before calling getSelectedReleases
2. Passes the correct flags to getSelectedReleases
3. Sets st.Releases to selectedAndNeededReleases instead of deduplicated
4. Passes IncludeNeeds=false and IncludeTransitiveNeeds=false to PlanReleases
since the needs are already included in selectedReleases
Signed-off-by: yxxhero <aiopsclub@163.com>
- Add IncludeNeeds to diff, template, lint, unittest, sync, apply ChartPrepareOptions
- All ConfigProviders already have DAGConfig embedded which includes IncludeNeeds()
Signed-off-by: yxxhero <aiopsclub@163.com>
- Add IncludeNeeds() to WriteValuesConfigProvider interface
- Implement IncludeNeeds() in WriteValuesImpl
- Update WriteValues function to use IncludeNeeds and IncludeTransitiveNeeds
Signed-off-by: yxxhero <aiopsclub@163.com>
- Add IncludeNeeds() to DepsConfigProvider and ReposConfigProvider
- Update depsConfig in tests
- Use c.IncludeNeeds() in run.go instead of hardcoded false
Signed-off-by: yxxhero <aiopsclub@163.com>
- Add IncludeNeeds() method to DepsConfigProvider interface
- Implement IncludeNeeds() in DepsImpl
- Update depsConfig in tests
- Use c.IncludeNeeds() in run.go instead of hardcoded false
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>
* feat: add --force-conflicts flag support for Helm 4
Add support for Helm 4's --force-conflicts flag which forces server-side
apply changes against conflicts. This flag is mutually exclusive with
--force/--force-replace and only available in Helm 4.
Fixes#2429
Signed-off-by: yxxhero <aiopsclub@163.com>
* fix: address review comments on force-conflicts feature
- Fix comment grammar: 'forces' instead of 'force'
- Improve error messages to indicate both sources (releases[] and helmDefaults)
- Add test case for helmDefaults.forceConflicts with Helm 3 (should error)
- Update TestGenerateID expected hashes after adding ForceConflicts field to structs
Signed-off-by: yxxhero <aiopsclub@163.com>
---------
Signed-off-by: yxxhero <aiopsclub@163.com>
* build(deps): bump Helm from v4.1.1 to v4.1.3
- Update Helm version to v4.1.3 in Dockerfiles (Alpine, Ubuntu, Debian)
- Update Helm version in CI workflow
- Update SHA256 checksums for amd64 and arm64 architectures
- Update go.mod dependency
Signed-off-by: yxxhero <aiopsclub@163.com>
* build(deps): bump Helm from v3.20.0 to v3.20.1
Signed-off-by: yxxhero <aiopsclub@163.com>
* go mod tidy
Signed-off-by: yxxhero <aiopsclub@163.com>
---------
Signed-off-by: yxxhero <aiopsclub@163.com>
* fix: use --force-replace flag for Helm 4 instead of deprecated --force
Helm 4 deprecated the --force flag in favor of --force-replace.
This fix detects the Helm version and uses the appropriate flag:
- Helm 4: --force-replace
- Helm 3: --force
Also fixed a nil pointer panic in appendHideNotesFlags when called
with nil SyncOpts.
Fixes#2476
Signed-off-by: yxxhero <aiopsclub@163.com>
* fix(ci): pin semver to v2.12.0 for Go 1.25 compatibility
semver@latest requires Go 1.26.1 but the project uses Go 1.25.4.
Pinning to v2.12.0 which is compatible with Go 1.25.
Signed-off-by: yxxhero <aiopsclub@163.com>
* test: add test cases for force flag from defaults with nil release
Add test cases to cover the scenario where release.Force is nil and
HelmDefaults.Force enables force for both Helm 3 and Helm 4.
Signed-off-by: yxxhero <aiopsclub@163.com>
* test: add nil ops test and rename misleading test names
- Add test case for appendHideNotesFlags with ops=nil to prevent
regression
- Rename force-from-default-nil-release-* to
force-from-default-nil-force-* for clarity (release.Force is nil,
not the release itself)
Signed-off-by: yxxhero <aiopsclub@163.com>
* refactor: add explicit parentheses for force condition
Add explicit parentheses around the two disjuncts in the force
condition to make the intended grouping unambiguous and easier
to read.
Signed-off-by: yxxhero <aiopsclub@163.com>
* refactor: check ops nil before Helm version in appendHideNotesFlags
- Swap the order to check ops == nil first to avoid unnecessary
IsVersionAtLeast call
- Restore the "see Helm release" comment for consistency with other
flag helpers
Signed-off-by: yxxhero <aiopsclub@163.com>
---------
Signed-off-by: yxxhero <aiopsclub@163.com>
PR #2367 introduced CLIOverrides to give --state-values-set element-by-element
array merge semantics. However, nested helmfile values (helmfiles[].values:)
were also routed into CLIOverrides, causing their arrays to merge instead of
replace. This broke the pre-v1.3.0 behavior where passing an array via
helmfiles[].values: would fully replace the child's default array.
Add OverrideValuesAreCLI flag to SubhelmfileEnvironmentSpec so the loader can
distinguish CLI flags from nested helmfile values. CLI values continue using
CLIOverrides (element-by-element merge); nested helmfile values now use Values
(Sparse merge strategy → full array replacement).
Fixes#2451
Signed-off-by: Aditya Menon <amenon@canarytechnologies.com>
Add new documentation explaining how Helmfile merges values from various sources:
- Core architecture and data flow
- Values sources and precedence order
- Deep merge behavior for maps and arrays
- Environment-specific value handling
- Secret management and priorities
- Common patterns and troubleshooting
This guide helps users understand the foundational concepts needed for
writing effective helmfiles, especially regarding value overrides and
merge strategies.
Signed-off-by: yxxhero <aiopsclub@163.com>
Add support for trackMode: helm-legacy to use Helm v4's --wait=legacy flag,
which maintains compatibility with Helm v3's wait behavior during migration.
Helm v4 changed the default --wait behavior from polling to a watcher-based
approach. This can cause issues with charts that have broken livenessProbe
configurations without startupProbe. The --wait=legacy flag preserves the
Helm v3 polling behavior for smoother migration.
Changes:
- Add TrackModeHelmLegacy constant in pkg/kubedog/options.go
- Use kubedog.TrackMode constants instead of raw strings in helmx.go
- Enhance appendWaitFlags to use --wait=legacy for Helm v4 when trackMode
is helm-legacy
- Add nil check for logger before logging warning
- Add version check with warning when helm-legacy is used with Helm v3
- Update validation in pkg/config to accept helm-legacy track mode
- Update command-line flags in cmd/apply.go and cmd/sync.go
- Add comprehensive documentation in docs/advanced-features.md
- Add thorough test coverage including warning message verification
Behavior:
- Helm v4 + helm-legacy: Uses --wait=legacy
- Helm v3 + helm-legacy: Falls back to --wait with warning
- Helm v4 + helm: Uses --wait (watcher mode)
- Any + kubedog: Skips --wait flag
Fixes#2464
Signed-off-by: yxxhero <aiopsclub@163.com>
Co-authored-by: Copilot <copilot@github.com>
Generated with Changesmith based on git history and release tags.
Covers v1.4.1 to v1.4.0 to v1.3.2 to v1.3.1.
Signed-off-by: MrPhil (Philip Ludington) <mrphil@mrphilgames.com>
yxxhero
dependabot[bot]
yxxhero
Aditya Menon
MrPhil (Philip Ludington)