feat: allow loading configurations from parent directories#6126
feat: allow loading configurations from parent directories#6126yaswanthkumar1995 wants to merge 1 commit intokubernetes-sigs:masterfrom
Conversation
Add RestrictionRootAndAncestors load restrictor that permits the configurations field to reference files in ancestor directories, enabling shared config (e.g., nameReference) across multiple kustomizations without duplication. Fixes kubernetes-sigs#6124
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yaswanthkumar1995 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
|
Welcome @yaswanthkumar1995! |
|
Hi @yaswanthkumar1995. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
Fixes #6124
What this PR does
Allows the
configurationsfield inkustomization.yamlto reference files in parent directories (e.g.,configurations: [../kustomizeconfig.yaml]).Previously, this was blocked by the
RestrictionRootOnlyload restrictor, forcing users to duplicate shared configuration files across every overlay.Changes
RestrictionRootAndAncestorsload restrictor that permits files in root and ancestor directories, while still blocking sibling/unrelated pathsWithLoadRestrictormethod toFileLoaderfor per-field restriction overridesconfigurationsfield inkusttarget.goWhy
Configuration files (nameReference, varReference, etc.) are metadata commonly shared across multiple kustomizations. Unlike resources or patches, they don't contain actual Kubernetes objects — they only define how kustomize should process fields. Requiring them to live under each overlay leads to duplication and drift.
How to test