yxxhero ca8fc293e9 fix: helmBinary setting ignored in multi-document YAML files (#2414)
* fix: helmBinary setting ignored in multi-document YAML files

The helmBinary setting in helmfile.yaml was being ignored when using
multi-document YAML files (files with --- separators).

Root Cause:
When processing multi-document YAML files, the load() function splits
the file into parts and processes each part separately. Each part was
calling applyDefaultsAndOverrides() which would set an empty helmBinary
to the default 'helm'. When merging parts, the default value from a
later part would override the correct value from an earlier part.

Fix:
- Added a new applyDefaults parameter to ParseAndLoad() to control when
  defaults are applied
- Modified rawLoad() to pass applyDefaults=false when processing
  individual parts
- Added a call to ApplyDefaultsAndOverrides() after all parts are merged
  to apply defaults once on the final merged state
- Exported ApplyDefaultsAndOverrides() method for use by the app package

Fixes: #2319
Signed-off-by: yxxhero <aiopsclub@163.com>

* fix: update comment per PR review

Change 're-apply' to 'apply' since defaults are never applied during
part processing (applyDefaults=false is passed), so this is the first
and only time defaults are applied to the merged state.

Signed-off-by: yxxhero <aiopsclub@163.com>

* fix: clarify applyDefaults logic in test LoadFile callbacks

Add explicit applyDefaults variable with comment explaining why it
equals evaluateBases: base files shouldn't apply defaults, only the
main file should after all parts/bases are merged.

Signed-off-by: yxxhero <aiopsclub@163.com>

* fix: address PR review comments

- Remove applyDefaults parameter from rawLoad() since it's always false
- Add regression test for multi-document YAML with helmBinary (issue #2319)

Signed-off-by: yxxhero <aiopsclub@163.com>

* test: add integration test for helmBinary in multi-document YAML

Add TestHelmBinaryPreservedInMultiDocumentYAML that exercises the full
loadDesiredStateFromYaml path to ensure helmBinary from the first
document is preserved when merging multi-document YAML files.

This is a regression test at the load() orchestration level for issue #2319.

Signed-off-by: yxxhero <aiopsclub@163.com>

---------

Signed-off-by: yxxhero <aiopsclub@163.com>
2026-02-20 22:12:38 +08:00
…
…
2026-02-20 15:27:21 +08:00
…
…
2024-08-24 05:14:38 +08:00

Helmfile

Tests Container Image Repository on GHCR Go Report Card Slack Community #helmfile Documentation Gurubase zread

Deploy Kubernetes Helm Charts

English | 简体中文

About

Helmfile is a declarative spec for deploying helm charts. It lets you...

  • Keep a directory of chart value files and maintain changes in version control.
  • Apply CI/CD to configuration changes.
  • Periodically sync to avoid skew in environments.

To avoid upgrades for each iteration of helm, the helmfile executable delegates to helm - as a result, the following must be installed

Highlights

Declarative: Write, version-control, apply the desired state file for visibility and reproducibility.

Modules: Modularize common patterns of your infrastructure, distribute it via Git, S3, etc. to be reused across the entire company (See #648)

Versatility: Manage your cluster consisting of charts, kustomizations, and directories of Kubernetes resources, turning everything to Helm releases (See #673)

Patch: JSON/Strategic-Merge Patch Kubernetes resources before helm-installing, without forking upstream charts (See #673)

Status

May 2025 Update

  • Helmfile v1.0 and v1.1 has been released. We recommend upgrading directly to v1.1 if you are still using v0.x.
  • If you haven't already upgraded, please go over this v1 proposal here to see a small list of breaking changes.

Installation

1: Binary Installation

download one of releases

2: Package Manager

  • Archlinux: install via pacman -S helmfile
  • openSUSE: install via zypper in helmfile assuming you are on Tumbleweed; if you are on Leap you must add the kubic repo for your distribution version once before that command, e.g. zypper ar https://download.opensuse.org/repositories/devel:/kubic/openSUSE_Leap_\$releasever kubic
  • Windows (using scoop): scoop install helmfile
  • macOS (using homebrew): brew install helmfile
  • Linux/macOS/Windows (using mise): mise use -g helmfile@latest

3: Container

For more details, see run as a container

Make sure to run helmfile init once after installation. Helmfile uses the helm-diff plugin.

Getting Started

Let's start with a simple helmfile and gradually improve it to fit your use-case!

Suppose the helmfile.yaml representing the desired state of your helm releases looks like:

repositories:
- name: prometheus-community
  url: https://prometheus-community.github.io/helm-charts

releases:
- name: prom-norbac-ubuntu
  namespace: prometheus
  chart: prometheus-community/prometheus
  set:
  - name: rbac.create
    value: false

Sync your Kubernetes cluster state to the desired one by running:

helmfile apply

Congratulations! You now have your first Prometheus deployment running inside your cluster.

Iterate on the helmfile.yaml by referencing:

More complex examples

See: multi-env-helmfile

Docs

Please read complete documentation

Contributing

Welcome to contribute together to make helmfile better: contributing doc

Attribution

We use:

  • semtag for automated semver tagging. I greatly appreciate the author(pnikosis)'s effort on creating it and their kindness to share it!

Users

Helmfile has been used by many users in production:

For more users, please see: Users

License

MIT

Star History

Star History Chart

S
Description
Declaratively deploy your Kubernetes manifests, Kustomize configs, and Charts as Helm releases in one shot
Readme
78 MiB
Languages
Go 92.7%
Shell 6.5%
Dockerfile 0.4%
Makefile 0.3%