Name in a configMapRef is not updated to include suffix/prefix when namespace is defined

[safizn]

What happened?

The same issue appears when using a namespace in the base kustomization.yml. I don't think it is intentional.

Issue

ConfigMap hash generated metadata.name doesn't match Deployment spec.template.spec.containers.envFrom.configMapRef.name; when base kustomization specifies a namespace.

Reproduce

Files at: https://gist.github.com/safizn/a37f399fb2706cf8d73331f42b840ddf

base/deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  template: 
    spec: 
      containers:
        - name: container
          envFrom: 
          - configMapRef:
              name: configuration

base/kustomization.yml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources: 
- deployment.yml
namespace: A

overlay/kustomization.yml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources: 
- ../base
namePrefix: dev- 
configMapGenerator:
- name: configuration

Expected result

apiVersion: v1
kind: ConfigMap
metadata:
  name: dev-configuration-6ct58987ht
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-deployment
  namespace: A
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: dev-configuration-6ct58987ht
        name: container

Actual result

apiVersion: v1
kind: ConfigMap
metadata:
  name: dev-configuration-6ct58987ht
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-deployment
  namespace: A
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: configuration
        name: container

Difference

$ diff with_namespace.txt without_namespace.txt 
10d9
<   namespace: A
17c16
<             name: configuration
---
>             name: dev-configuration-6ct58987ht

Versions

Linux

$ kubectly version
Client Version: v1.32.0
Kustomize Version: v5.5.0

[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-sigs/prow repository.

[safizn]

related to #5047