helmChart with CRD is untargetable by component patch

[tis-rpage]

There appears to be an incompatibility with helmCharts and components in the same kustomization file. When attempting to use a patch in a component, the helmChart resources are untargetable due to [noNs].

Error:

Error: accumulating components: accumulateDirectory: "recursed accumulation of path 'foobar/component': no matches for Id CustomResourceDefinition.v1.apiextensions.k8s.io/adoptedresources.services.k8s.aws.[noNs]; failed to find unique target for patch CustomResourceDefinition.v1.apiextensions.k8s.io/adoptedresources.services.k8s.aws.[noNs]"

Reproduction:

mkdir -p foobar/{base,broken,overlay,component}
helm pull oci://public.ecr.aws/aws-controllers-k8s/rds-chart --version v0.0.19 --untar --untardir foobar/base/charts
helm pull oci://public.ecr.aws/aws-controllers-k8s/rds-chart --version v0.0.19 --untar --untardir foobar/broken/charts

<<-EOF cat > foobar/base/kustomization.yaml
helmCharts:
  - namespace: ack
    name: rds-chart
    repo: oci://public.ecr.aws/aws-controllers-k8s/rds-chart
    version: v0.0.19
    releaseName: ee
    includeCRDs: true
EOF


<<-EOF cat >> foobar/broken/kustomization.yaml
helmCharts:
  - namespace: ack
    name: rds-chart
    repo: oci://public.ecr.aws/aws-controllers-k8s/rds-chart
    version: v0.0.19
    releaseName: ee
    includeCRDs: true

components:
  - ../component
EOF


<<-EOF cat > foobar/overlay/kustomization.yaml
bases:
  - ../base

components:
  - ../component
EOF


<<-EOF cat > foobar/component/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

patches:
  - patch: |-
      \$patch: delete
      apiVersion: apiextensions.k8s.io/v1
      kind: CustomResourceDefinition
      metadata:
        name: adoptedresources.services.k8s.aws
EOF

Results:
✔️ kustomize build --enable-helm foobar/overlay/
✔️ kustomize build --enable-helm foobar/base/
⛔ kustomize build --enable-helm foobar/broken/

Expected Results:
✔️ kustomize build --enable-helm foobar/overlay/
✔️ kustomize build --enable-helm foobar/base/
✔️ kustomize build --enable-helm foobar/broken/

[k8s-ci-robot]

@tis-rpage: 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.

[KnVerey]

The reason for this is the order in which Kustomize processes the fields in a Kustomization. The order is resources (including components), then generators (including Helm), then transformers. If we were to fix #4402, then you would be able to specify a bespoke order within your Kustomization's transformers field, but until that is done, it is not possible to reorder resources or transformers specifically. The structure you have overlay example is the intended usage for now.

/triage duplicate (resolved by #4402)
/kind feature

[k8s-ci-robot]

@KnVerey: The label(s) triage/(resolved, triage/by, triage/https://github.com/kubernetes-sigs/kustomize/issues/4402) cannot be applied, because the repository doesn't have them.

In response to this:

The reason for this is the order in which Kustomize processes the fields in a Kustomization. The order is resources (including components), then generators (including Helm), then transformers. If we were to fix #4402, then you would be able to specify a bespoke order within your Kustomization's transformers field, but until that is done, it is not possible to reorder resources or transformers specifically. The structure you have overlay example is the intended usage for now.

/triage duplicate (resolved by #4402)
/kind feature

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale