Documentation
¶
Overview ¶
Package helmcmd contains small helpers for invoking the pinned helm binary.
The main job here is keeping `helmfile sync` working across helm major versions. Helm 4 turned server-side apply on by default; SSA introduces field-ownership conflicts (the apiserver synthesises a "before-first-apply" manager for any field that pre-existed the first SSA call) that helm 4 only takes over when --force-conflicts is passed. Helm 3 used client-side apply, has no SSA and rejects --force-conflicts as an unknown flag, so the flag must only be appended on helm 4+.
Index ¶
- func EnsureRepos(helmBinary string, repos []helmfileRepo) error
- func Helmfile(helmfileBinary, helmBinary string, args ...string) *exec.Cmd
- func MajorVersion(helmBinary string) (int, error)
- func ParseHelmfileRepos(helmfilePath string) ([]helmfileRepo, error)
- func RepoUpdateSupportsFailOnRepoUpdateFail(helmBinary string) bool
- func SyncFlagsForVersion(helmBinary string) []string
- func UpdateRepos(helmBinary string, names []string) ([]byte, error)
- type ReleaseHealth
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func EnsureRepos ¶ added in v0.10.0
EnsureRepos registers each (name, url) pair via `helm repo add --force-update` so that a fresh host without `helm repo add` for our managed repos still gets them registered before we ask helm to update them by name. Best-effort: failures are returned for visibility but should not be treated as fatal by callers (the subsequent `helm repo update` will surface real problems).
func Helmfile ¶ added in v0.15.0
Helmfile builds a helmfile command that is pinned to helmBinary via --helm-binary. Without it helmfile runs whatever `helm` is first on PATH, while SyncFlagsForVersion probes the obol-resolved binary: with a Helm 4 on PATH and the pinned Helm 3 in the bin dir, sync ran Helm 4's server-side apply WITHOUT --force-conflicts and failed on field-manager conflicts (e.g. a Secret previously written by `kubectl apply`). Use this for every helmfile invocation so the probed and executed helm match.
func MajorVersion ¶
MajorVersion runs `<helmBinary> version --short` and returns the major version integer (3, 4, ...). Returns an error if helm cannot be invoked or the output is unparseable.
func ParseHelmfileRepos ¶ added in v0.10.0
ParseHelmfileRepos extracts (name, url) entries from a helmfile.yaml file. Repos without both a name and a URL (e.g. OCI-only refs) are skipped — they are not added via `helm repo add` so they don't participate in the `helm repo update` path that this package guards against.
func RepoUpdateSupportsFailOnRepoUpdateFail ¶ added in v0.10.0
RepoUpdateSupportsFailOnRepoUpdateFail reports whether the current helm binary accepts `helm repo update --fail-on-repo-update-fail=false`.
Do not infer this from the major version. Some Helm 4 builds dropped the flag even though Helm 3.14+ had it, and passing an unknown flag prevents the targeted repo update from running at all.
func SyncFlagsForVersion ¶
SyncFlagsForVersion returns the extra `helmfile sync` flags needed for the detected helm version. On helm 4+ this is --sync-args=--force-conflicts so helm's SSA upgrade can take ownership of fields previously written by other managers (e.g. `kubectl apply`, the `obol model setup` patch on litellm-config.data.config.yaml, or fields recorded under the synthetic "before-first-apply" manager). On helm 3 this returns nil — helm 3 uses client-side apply and rejects --force-conflicts.
Detection failures degrade silently to nil so a missing/old helm binary doesn't block the user; the helmfile sync will still surface the real error.
func UpdateRepos ¶ added in v0.10.0
UpdateRepos runs `helm repo update <names...>` and, when the helm binary advertises support, passes --fail-on-repo-update-fail=false so that a single dead repo doesn't abort the whole update.
Behaviour:
- helm versions that advertise --fail-on-repo-update-fail: the flag is passed and the returned error is nil even if individual repos in `names` fail.
- other helm versions: the flag is omitted and the error surfaces normally.
The targeted form (`helm repo update <names...>`) is important: it limits the update to repos this stack actually needs, so unrelated dead repos in the user's global helm config can't break us even on helm versions that lack the tolerant flag.
Types ¶
type ReleaseHealth ¶ added in v0.15.0
type ReleaseHealth int
ReleaseHealth summarises the helm releases in one namespace.
const ( // ReleasesMissing: no release at all in the namespace (fresh cluster). ReleasesMissing ReleaseHealth = iota // ReleasesUnhealthy: at least one release is not in "deployed" state // (failed, pending-install, pending-upgrade, ...). ReleasesUnhealthy // ReleasesDeployed: every release in the namespace is deployed. ReleasesDeployed )
func NamespaceReleaseHealth ¶ added in v0.15.0
func NamespaceReleaseHealth(helmBinary, kubeconfig, namespace string) (ReleaseHealth, error)
NamespaceReleaseHealth runs `helm list -n <ns> -a -o json` and classifies the result. Cheap (one helm call, no chart rendering), so record replay can use it to decide whether an expensive `helmfile sync` is needed at all.
func ParseReleaseHealth ¶ added in v0.15.0
func ParseReleaseHealth(out []byte) (ReleaseHealth, error)
ParseReleaseHealth classifies `helm list -o json` output.
func (ReleaseHealth) String ¶ added in v0.15.0
func (h ReleaseHealth) String() string
Source Files