* feat: allow helmfile to continue on failed releases
Co-authored-by: Peter Honeder <peter.honeder@unwired.at>
Signed-off-by: Niklas Ott <niklas.ott@unwired.at>
* fix: skip failed-prep releases, complete flag wiring, add tests and docs (#64)
Review follow-ups for --allow-failed-releases (#2616):
- Track per-release chart preparation failures in PrepareCharts (returned
as a map keyed by release) and remove those releases from the state in
Run.WithPreparedCharts when --allow-failed-releases is set, so a failed
release is never executed against its original, un-prepared chart
reference (which could either fail again with a duplicate error or, for
charts requiring chartify, bypass patches/dependency modifications and
produce an unintended result). All failures are still reported at the
end via the aggregated MultiError.
- Complete the release identity on error results from
prepareChartForRelease so failures are attributed to the correct
release.
- With --allow-failed-releases, continue building dependencies of the
remaining charts when 'helm dep build' fails for one release, and skip
the affected releases during execution.
- Wire --allow-failed-releases into 'helmfile unittest' and 'helmfile
status'; remove the dead flag wiring for write-values and list (both
never prepare charts, see commandsSkipChartPrep).
- Simplify control flow (guard clauses, errors.As, drop dead code and
redundant else branches).
- Add end-to-end coverage in pkg/app/issue_2616_test.go and extend the
state-level tests; document the flag in docs/cli.md and CHANGELOG.md.
Signed-off-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
---------
Signed-off-by: Niklas Ott <niklas.ott@unwired.at>
Signed-off-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
Co-authored-by: Peter Honeder <peter.honeder@unwired.at>
Co-authored-by: yxxhero <11087727+yxxhero@users.noreply.github.com>
* fix(state): prefetch shared remote charts instead of serializing sync/diff (#2741)
PR #2662 fixed a Windows chart-download race (#768) by wrapping the entire
helm upgrade/diff operation in a per-chart+version lock, not just the
download. Since sync/apply/diff never set ForceDownload, releases sharing a
remote chart end up fully serialized even at high --concurrency.
Add ChartPrepareOptions.PrefetchSharedRemoteCharts: PrepareCharts groups
selected releases by chart+version, and force-downloads (once) any chart
used by 2+ releases that also resolve to identical acquisition flags
(--verify/--keyring/--plain-http/--insecure-skip-tls-verify/--devel) and to
a configured repository (or OCI ref) - not a bare \"dir/chart\"-shaped local
path. That materializes release.ChartPath, which lets withChartOperationLock's
existing ChartPath != \"\" guard skip the lock, restoring concurrency without
touching the #768 protection for charts that aren't prefetched.
Also add chartFetchFlags to give forcedDownloadChart's \`helm fetch\` the same
verify/keyring/TLS flags flagsForUpgrade already applies, closing a parity
gap that predates this change (affects lint/unittest/pull too).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Thomas Hanser <gh@toms.place>
* fix(state): exclude verify-enabled charts from shared-chart prefetch, use NUL-delimited flag signature
Copilot review on #2741's PR flagged two issues in the shared-chart prefetch
added there:
1. forcedDownloadChart untars a shared chart into a local directory, but
flagsForUpgrade unconditionally re-adds --verify for the later `helm
upgrade` regardless of ChartPath. Helm's VerifyChart only accepts a
packaged .tgz/provenance pair, not an unpacked directory, so upgrading a
prefetched chart with verify enabled would fail. Exclude --verify from
prefetch eligibility entirely rather than trying to suppress the later
flag - those releases just keep the pre-existing serialized-lock
behavior, unaffected by this feature.
2. The per-key flag-agreement signature joined flags with a space, which
isn't injective: a keyring path containing a space and a flag-like token
could collide with a different keyring plus a real flag, silently
deduplicating releases with different acquisition settings. Join with
NUL instead, which can't appear in an OS argument.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Thomas Hanser <gh@toms.place>
* fix(state): apply -chart override before shared-chart grouping
Copilot flagged that PrepareCharts grouped releases by release.Chart
before prepareChartForRelease applied st.OverrideChart (the -chart CLI
flag), so distinct original charts that all resolve to the same
overridden chart were never recognized as shared and missed the
prefetch. Apply the override once upfront, before the grouping loop
reads release.Chart.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Thomas Hanser <gh@toms.place>
---------
Signed-off-by: Thomas Hanser <gh@toms.place>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
