The side-effect is that local resources from a base will be exposed to overlays. Can you think of any reason that's undesirable? I was surprised it wasn't already the case, personally.

I don't see any reason why the local base resources shouldn't be exposed to overlays. I think this makes sense.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KnVerey, natasha41575

The full list of commands accepted by this bot can be found here.

The pull request process is described here

The side-effect is that local resources from a base will be exposed to overlays. Can you think of any reason that's undesirable? I was surprised it wasn't already the case, personally.

@KnVerey one side effect that we've now encountered is that a local-only configMapGenerator in a component used in multiple resources now has a name collision when those resources are combined into one kustomization. We're attempting to use replacements to change the registry domain of an image on a per-environment basis, and the only reason we use a configMapGenerator at all is because replacements can't reference constant values defined inline. Our approach works in 4.5.5, but breaks in 5.0.0 and above, I believe because of this change.

I have the same issue with this a @wyattanderson. I am using replacements with a local-config confgiMapGenerator to differentiate blue/green deployments.

We want to gather more information before making a decision on this change.

We're attempting to use replacements to change the registry domain of an image on a per-environment basis, and the only reason we use a configMapGenerator at all is because replacements can't reference constant values defined inline.

@wyattanderson please feel free to open your own issue on this regression. Are there any workarounds for your use case? For example, you can

• specify constant values with patches; though, it doesn't have the parsing abilities of replacements
• move the reference to your Component into the overlay