helmfile: OCI chart refs with @sha256: digest are dropped as unsupported-chart-type

[RahulGautamSingh]

Discussed in #45054

^{Originally posted by ribbybibby August 4, 2026}

Description

The helmfile manager drops any release whose chart: includes an inline @sha256:... digest, marking it unsupported-chart-type. The digest is a valid part of an OCI reference, so this is a false rejection and the dependency is silently lost rather than updated.

Reproduction

Minimal repro: https://github.com/ribbybibby/renovate-helmfile-oci-digest-repro

helmfile.yaml:

releases:
  - name: grafana
    chart: oci://ghcr.io/grafana/helm-charts/grafana@sha256:3d75dc3173c3fb07eaa8853283f38558c7c27259f7ed00cf8c096173667426a1
    version: 10.5.15

Current behaviour

{
  "depName": "ghcr.io/grafana/helm-charts/grafana@sha256:3d75dc31…",
  "packageName": "ghcr.io/grafana/helm-charts/grafana@sha256:3d75dc31…",
  "currentValue": "10.5.15",
  "datasource": "docker",
  "skipReason": "unsupported-chart-type"
}

Expected behaviour

• The @sha256:... digest is split into currentDigest and excluded from packageName/depName.
• Version updates work as they do for digest-free OCI charts.
• Ideally, the digest in chart: is also updatable.

Root cause

In lib/modules/manager/helmfile/extract.ts, an oci:// chart becomes packageName = depName = removeOCIPrefix(dep.chart) with the digest still attached. The name is then validated by isValidChartName, whose OCI regex rejects @. The last path segment is grafana@sha256:..., so validation fails and skipReason is set to unsupported-chart-type before any datasource lookup runs.

Two levels of fix:

1. Split the digest into currentDigest and strip it from the name before validation, so the dep is no longer dropped and version updates resume.
2. Add a replaceString/update path so the digest in chart: can be rewritten (digest updates are currently not wired in the helmfile manager at all).

[ribbybibby]

Thank you @RahulGautamSingh!

One small comment:

Ideally, the digest in chart: is also updatable.

I would say this is essential, not just ideal. Updating the version for a digest-pinned reference is meaningless, as the digest takes precedence when the chart is pulled. It would be potentially deceiving to bump the version but leave the digest as-is.

So I would say that if a digest is present, then Renovate needs to be updating it along with the version.