.Capabilities.APIVersions.Has incorrectly filled when using helm v4.0.0

[BernhardGruen]

Hello,

we are seeing different outputs for the following two combinations:

• helm-diff v3.14.1, helm v4.0.0 and Helmfile v1.2.1
• helm-diff v3.14.1, helm v3.19.2 and Helmfile v1.2.1

With helm v4.0.0 it seems that the following code is evaluated differently by helm-diff:

{{ if .Capabilities.APIVersions.Has "monitoring.coreos.com/v1/PrometheusRule" }}
{{ template "prometheusrule.tpl" . }}
{{ end }}

helm-diff shows that the code block would be deleted by the deployment but helm v4.0.0 does not remove it.

If this deployment is executed with helm v3.19.2 that block is not shown as code to be removed (and also not removed by helm v3.19.2).

Therefore I think the helm-diff plugin evaluates .Capabilities.APIVersions.Has in a different/wrong way when running with helm v4.0.0.

[yxxhero]

@BernhardGruen https://github.com/helm/helm/issues/31508 did you try to use helm v4.0.1?

[senanjude0]

happening with helm 4.0.1

helm version
version.BuildInfo{Version:"v4.0.1", GitCommit:"12500dd401faa7629f30ba5d5bff36287f3e94d3", GitTreeState:"clean", GoVersion:"go1.25.4", KubeClientVersion:"v1.34"}

for example had to pass these along with the helm diff command to make it work

  --api-versions "networking.istio.io/v1beta1/DestinationRule" \
  --api-versions "networking.istio.io/v1alpha3/ServiceEntry" \

[BernhardGruen]

At the time of writing this issue helm 4.0.1 was not yet released. But it seems 4.0.1 is still affected by this issue - unfortunately.

@senanjude0 thank you for your input. This should solve most of our problems for the moment. But it does not solve the following situation: If I provide a CRD version via --api-versions which is not really available on a specific cluster (we have about 60) it could generate a code block which should not be there. This then will trigger an unnecessary apply and also fill up our logs with logs that don't reflect the reality anymore.

[BernhardGruen]

@yxxhero do you think this is an error or an oversight in the plugin architecture of helm v4 and therefore should be reported there?

[BernhardGruen]

Just a quick follow up: Using Helm 4.0.2 the issue is still present.

[gclawes]

Seeing this with a couple of different charts:

root@a3ab9cd61f72:~# helm version
version.BuildInfo{Version:"v4.0.4", GitCommit:"8650e1dad9e6ae38b41f60b712af9218a0d8cc11", GitTreeState:"clean", GoVersion:"go1.25.5", KubeClientVersion:"v1.34"}
root@a3ab9cd61f72:~# helm plugin list
NAME                    VERSION TYPE            APIVERSION      PROVENANCE      SOURCE
diff                    3.14.1  cli/v1          legacy          unknown         unknown

bjw-s-labs/app-template https://github.com/bjw-s-labs/helm-charts/blob/cb4e494e7127fc1ec4e58b6932f391379598259c/charts/library/common/templates/classes/_route.tpl#L9-L16

root@a3ab9cd61f72:~# helm diff --suppress-secrets upgrade whoami bjw-s/app-template --namespace whoami --version 4.5.0 -f turing-cluster/helm/whoami-values.yaml
whoami, whoami-gw, HTTPRoute (gateway.networking.k8s.io) has changed:
  # Source: app-template/templates/common.yaml
- apiVersion: gateway.networking.k8s.io/v1
+ apiVersion: gateway.networking.k8s.io/v1alpha2
  kind: HTTPRoute
  metadata:
    name: whoami-gw
...

grafana/k8s-monitoring https://github.com/grafana/k8s-monitoring-helm/blob/b0e967aea582858a1dc42c20e1af61ec4124311f/charts/k8s-monitoring/templates/_crd-validation.tpl#L19

root@a3ab9cd61f72:~# helm diff --suppress-secrets upgrade k8s-monitoring grafana/k8s-monitoring --namespace k8s-monitoring --version 3.6.2 -f turing-cluster/helm/k8s-monitoring-values.yaml
Error: Failed to render chart: exit status 1: Error: execution error at (k8s-monitoring/templates/alloy.yaml:2:4):
The k8s-monitoring Helm chart v3.0 requires the Alloy CRD to be deployed.
Before upgrading, please install the Alloy CRD:
kubectl apply -f https://github.com/grafana/alloy-operator/releases/download/alloy-operator-0.3.14/collectors.grafana.com_alloy.yaml

Use --debug flag to render out invalid YAML

Error: plugin "diff" exited with error

[gclawes]

Digging into the helm v4 changes (not an expert here, could be wrong), I'm wondering if it has anything to do with the change from DryRun to DryRunStrategy:

https://github.com/helm/helm/commit/f21b143befbca1a6d930ba4ac95c2e7d2c56d3c2#diff-5d4849bad97d2e075ce5d0ae5af3e93dbfde235ce1345fa96148279cf706af2fR301-R316

Specifically is helm no longer interacting with the apiserver by default to know what APIVersions are available?