-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exec KRM functions with relative paths don't resolve when base kustomization is in use #4350
Comments
@seh: 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 The 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. |
I confirmed that if you specify a relative path to the exec KRM function file from the base kustomization root, it works. That is, in the example introduced here, if the "exec.path" field's value is ../overlays/fn/plugins/change-color, then kustomize finds the change-color file. Clearly it's using the base kustomization directory as its working directory. Instead, it should use the directory of the overlay kustomization that includes the function. |
See #4347 for a similar complaint. |
/triage duplicate Thank you for the detailed report. Since this was opened slightly after #4347 (crazy timing!), let's continue there. |
@KnVerey: Closing this issue. In response to this:
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. |
Description
Following up from #4117, while #4125 made it possible to use relative paths to specify the location of an exec KRM function, that resolution only works correctly when the kustomization containing the KRM function does not use any bases, and instead includes only resources—specifically, references to files below that kustomization root.
The following kustomization.yaml files demonstrate the possibilities:
No resources
Relative KRM function paths work as expected.
Only resources
Relative KRM function paths work as expected.
Only bases
Relative KRM function paths do not work as expected.
Bases and resources
Relative KRM function paths do not work as expected.
Reproduction
Please consult the archive of a base kustomization and an overlay kustomization, where the overlay includes a KRM function.
kustomize-fn-defect.tar.gz
Preparation
Expected Output
Actual Output
Environment
Kustomize Version
{Version:kustomize/v4.4.1 GitCommit:b2d65ddc98e09187a8e38adc27c30bab078c1dbf BuildDate:2021-11-11T23:27:14Z GoOs:darwin GoArch:amd64}
Platform
macOS 11.6 (Darwin Kernel Version 20.6.0)
Additional Context
If you change the "exec.path" field (embedded in the "config.kubernetes.io/function" annotation) in the krm-functions.yaml file to the absolute path to the change-color program (e.g. /tmp/kustomize-demo/overlays/fn/plugins/change-color), then kustomize build works as expected. Likewise, if you use a relative path to the change-color file and comment out the resource ../../base in the overlay kustomization.yaml file and instead include the ConfigMap content in a file within the overlay's directory (effectively changing the overlay into a base), then kustomize build works as expected.
The text was updated successfully, but these errors were encountered: