docs(plugin): document KUSTOMIZE_PLUGIN_HOME and plugin-home resolution#6127
docs(plugin): document KUSTOMIZE_PLUGIN_HOME and plugin-home resolution#6127alliasgher wants to merge 2 commits into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alliasgher 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 @alliasgher! |
|
Hi @alliasgher. 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. |
Add a "Plugin home" section to plugin/README.md describing the order in which kustomize resolves the plugin home directory: 1. $KUSTOMIZE_PLUGIN_HOME 2. $XDG_CONFIG_HOME/kustomize/plugin 3. $HOME/.config/kustomize/plugin 4. $HOME/kustomize/plugin Also note the Windows $USERPROFILE fallback and the relative path layout used when loading an individual plugin. Content is taken directly from api/konfig/plugins.go and api/internal/plugins/loader. Signed-off-by: Ali <alliasgher123@gmail.com>
a20caf6 to
dc29d4b
Compare
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alliasgher 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 |
|
/ok-to-test |
| unset. | ||
| 4. `$HOME/kustomize/plugin`. | ||
|
|
||
| If none of the above exist, plugin resolution fails. On Windows, |
There was a problem hiding this comment.
On Windows, the code does not fall back from HOME to USERPROFILE; homeEnv() directly selects USERPROFILE instead of HOME. Please change this to something like: “On Windows, $USERPROFILE is used in place of $HOME.”
| 1. `$KUSTOMIZE_PLUGIN_HOME` — set this to override the default search | ||
| paths below (useful when plugins live outside `$HOME`). | ||
| 2. `$XDG_CONFIG_HOME/kustomize/plugin`. | ||
| 3. `$HOME/.config/kustomize/plugin` — used when `$XDG_CONFIG_HOME` is |
There was a problem hiding this comment.
The note for $HOME/.config/kustomize/plugin does not match the implementation. This candidate is always tried after $XDG_CONFIG_HOME/kustomize/plugin; it is not limited to the case where XDG_CONFIG_HOME is unset. If XDG_CONFIG_HOME is set but that directory does not exist, Kustomize still falls back to $HOME/.config/kustomize/plugin.
Could we describe this as the default XDG-style location, or explicitly say that it is also tried when the configured XDG path does not exist?
| matching the `apiVersion` and `kind` fields of the generator or | ||
| transformer entry in `kustomization.yaml`. | ||
|
|
||
| #### Testing |
There was a problem hiding this comment.
The new heading changes the document hierarchy so that #### Testing becomes a subsection of ### Plugin home. Since that section describes plugin testing in general, could we either move Plugin home after Testing or promote Testing to an ### heading?
| Within the plugin home, an individual plugin is loaded from | ||
| `<apiVersion group>/<apiVersion version>/<lowercase kind>/<Kind>`, | ||
| matching the `apiVersion` and `kind` fields of the generator or | ||
| transformer entry in `kustomization.yaml`. |
There was a problem hiding this comment.
Please distinguish the Exec and Go plugin paths. Kustomize first tries //// as an executable, then tries the same path with .so for a Go plugin.
Also, generators and transformers entries in kustomization.yaml are file paths. The apiVersion and kind are read from the referenced plugin configuration file, not directly from the list entry itself. An explicit example would make this much clearer.
There was a problem hiding this comment.
Updated: the docs now note that generators/transformers entries are file paths whose apiVersion and kind come from the referenced config file, and that kustomize resolves the derived path first as an executable (Exec plugin) then as .so (Go plugin), with an explicit SedTransformer example.
Signed-off-by: Ali <alliasgher123@gmail.com>
|
This PR has multiple commits, and the default merge method is: merge. 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. |
Summary
Adds a "Plugin home" section to `plugin/README.md` describing the directory kustomize uses to look up Exec and Go plugins.
The section documents the four-step resolution order kustomize applies to find the plugin home:
It also notes the Windows `$USERPROFILE` fallback for `$HOME` and the relative layout kustomize uses to load an individual plugin (`///`).
Content comes directly from `api/konfig/plugins.go` and `api/internal/plugins/loader/loader.go`.
Fixes #5706.
/kind documentation