.Capabilities.APIVersions.Has does not work in Helm charts when using Helm as a renderer

[jackwilsdon]

Expected behavior

.Capabilities.APIVersions.Has works in Helm charts when using Helm as a manifest renderer.

Actual behavior

.Capabilities.APIVersions is only populated with default API versions available to kubectl (not versions available in the cluster).

Information

• Skaffold version: v2.6.0
• Operating system: macOS Ventura 13.4.1
• Installed via: skaffold.dev
• Contents of skaffold.yaml:

  apiVersion: skaffold/v4beta5
  kind: Config
  manifests:
  helm:
    releases:
      - name: my-release
        chartPath: my-chart
  deploy:
  kubectl: {}

Steps to reproduce the behavior

1. Clone https://github.com/jackwilsdon/skaffold-capabilities-issue
2. skaffold run or skaffold render
3. Note that the generated ConfigMap only lists the default API versions and not any additional ones installed into the cluster

[ericzzzzzzz]

Hi, @jackwilsdon could you clarify what .Capabilities.APIVersions.Has works in Helm charts when using Helm as a manifest renderer. means? I'm not sure what the expected output.

Are there any differences between the result from helm template [name] [charFolder] and the one from skaffold render in your provided example?

[jackwilsdon]

When using Helm as a deployer, it uses helm install (or helm upgrade). This correctly populates .Capabilities.APIVersions in Helm templates with a list of all API versions provided by the cluster (including custom resources).

When using it as a manifest renderer, it uses helm template. This doesn't populate the API version list as it doesn't connect to the cluster. This can cause issues where a chart doesn't know that a specific API is available and can cause it to not install the required resources.

The expected output of skaffold render is a list of APIs available in the cluster (including custom resources), but it just outputs the default list of APIs provided by kubectl.

helm template offers an --api-versions flag which is used to tell it what API versions are available. Ideally, Skaffold would connect to the cluster, list the available API versions and append them to the helm template invocation.

[ericzzzzzzz]

Hi @jackwilsdon, thank you for the excellent explanation. It seems that we can use helm install --dry-run to include k8s cluster supported api versions in the render output. I think we can enable server side rendering in render stage, however this should not become a default behavior, as current render doesn't necessary require connecting to a cluster, making it default is a breaking change. I think we can this as optional and configurable to let users to decide which k8s context they want to use for server side rendering.

[jackwilsdon]

I didn't know about helm install --dry-run - that certainly looks like the tool for the job :+1:

skaffold render already offers an --offline flag, although I guess it would technically be a breaking change to have the Helm renderer start connecting to the cluster without this flag?