kustomize 5.0.2 breaks helmCharts w/ chartHome

[kenzht]

What happened?

Upgrading to 5.0.2 breaks helmCharts + chartHome. (which works fine in 5.0.1)

steps to reproduce:

$ cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmGlobals:
  chartHome: charts

helmCharts:
- releaseName: minecraft
  namespace: default
  name: minecraft
  version: 3.1.3
  includeCRDs: true
$ ls
charts  kustomization.yaml
$ ls charts/
minecraft  minecraft-3.1.3.tgz
$ ~/bin/kustomize.5.0.1 build --enable-helm
apiVersion: v1
data:
  rcon-password: Q0hBTkdFTUUh
kind: Secret
metadata:
  labels:
    app: minecraft-minecraft
    chart: minecraft-3.1.3
    heritage: Helm
    release: minecraft
  name: minecraft-minecraft
type: Opaque
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: minecraft-minecraft
    chart: minecraft-3.1.3
    heritage: Helm
    release: minecraft
  name: minecraft-minecraft
spec:
  ports:
  - name: minecraft
    port: 25565
    protocol: TCP
    targetPort: minecraft
  selector:
    app: minecraft-minecraft
  type: ClusterIP
$ ~/bin/kustomize.5.0.1 version
v5.0.1
$ ~/bin/kustomize.5.0.2 build --enable-helm
Error: no repo specified for pull, no chart found at ''
$ ~/bin/kustomize.5.0.2 version
v5.0.2
$

What did you expect to happen?

kustomize build succeeds.

How can we reproduce it (as minimally and precisely as possible)?

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmGlobals:
  chartHome: charts

helmCharts:
- releaseName: minecraft
  namespace: default
  name: minecraft
  version: 3.1.3
  includeCRDs: true

Expected output

apiVersion: v1
data:
  rcon-password: Q0hBTkdFTUUh
kind: Secret
metadata:
  labels:
    app: minecraft-minecraft
    chart: minecraft-3.1.3
    heritage: Helm
    release: minecraft
  name: minecraft-minecraft
type: Opaque
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: minecraft-minecraft
    chart: minecraft-3.1.3
    heritage: Helm
    release: minecraft
  name: minecraft-minecraft
spec:
  ports:
  - name: minecraft
    port: 25565
    protocol: TCP
    targetPort: minecraft
  selector:
    app: minecraft-minecraft
  type: ClusterIP

Actual output

Error: no repo specified for pull, no chart found at ''

Kustomize version

5.0.2

Operating system

Linux

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[natasha41575]

@dlish could you please take a look at this? This was almost certainly caused by #4999

[natasha41575]

Actually, I am not able to reproduce the issue here. Could you provide perhaps a sample directory with your charts that reproduces the issue?

Here is what I tried:

$ ls
helmcharts              kustomization.yaml

$ cat kustomization.yaml
helmGlobals:
  chartHome: helmcharts

helmCharts:
  - name: test-chart
    releaseName: test-chart

$ tree helmcharts
helmcharts/
└── test-chart
    ├── Chart.yaml
    ├── README.md
    ├── templates
    │   ├── _helpers.tpl
    │   ├── deployment.yaml
    │   └── tests
    │       └── test-pod.yaml
    └── values.yaml

$ kustomize build . --enable-helm
# this succeeds

Edited to add: Ah, I can now reproduce the issue if I include a version number. Digging further into it.

[natasha41575]

So it seems that #4999 introduced a breaking change that expects a different chartHome directory structure than previously. This does not affect users who are using remote charts, but it does impact users with existing local charts as they would be required to restructure their local charts.

Apologies @dlish, but given that this is a substantial breaking change I think the best course of action would be to revert #4999, re-release kustomize, and reintroduce your change again later while ensuring that it does not require users with local charts to change their existing directory structure. This is a rather unfortunate reflection that our e2e tests have gaps in coverage and we should try to cover the gaps as much as we can.

[natasha41575]

Reverted.