mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00

Files

Yannis Zarkadas a502717460 Make ordering configurable (#4019 )

* api: Add new types for customizeable resource ordering

Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>

* plugins: Implement SortOrderTransformer plugin

Implement the SortOrderTransformer plugin. This plugin allows the user
to customize the order that kustomize will output resources in.

The API for the plugin is the following:

sortOptions:
  order: legacy | fifo
  legacySortOptions:
    orderFirst:
    - {GVK}
    orderLast:
    - {GVK}

Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>

* plugins: Add boilerplate and generate code for new SortOrderTransformer

Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>

* build: Add option to denote if the reorder flag was set by the user

We want to take different actions if the reorder flag was set by the
user or filled by the default value. Thus, we propagate this information
from build to the krusty options.

Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

* api/krusty: Ensure sort ordering works with CLI flag and kustomization

Sort order can be defined in two places:
- (new) kustomization file
- (old) CLI flag
We want the kustomization file to take precedence over the CLI flag.

Eventually, we may want to move away from having a CLI flag altogether:
https://github.com/kubernetes-sigs/kustomize/issues/3947

Case 1: Sort order set in kustomization file AND in CLI flag.
Print a warning and let the kustomization file take precedence.

Case 2: Sort order set in CLI flag only or not at all.
Follow the CLI flag (defaults to legacy) and reorder at the end.

Case 3: Sort order set in kustomization file only.
Simply build the kustomization.

Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

* krusty: Add e2e test for SortOrderTransformer

Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>

* plugins: Purge LegacyOrderTransformer

Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

* Update go.work.sum

Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

* review: Make review changes

Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

Signed-off-by: Yannis Zarkadas <yanniszark@arrikto.com>
Signed-off-by: Yannis Zarkadas <yanniszark@gmail.com>

2022-12-02 13:59:53 -08:00

builtin

Make ordering configurable (#4019 )

2022-12-02 13:59:53 -08:00

someteam.example.com/v1

Fix pluginator incompatibility with nolint lines

2022-11-30 11:22:10 -05:00

untested/v1/gogetter

Update to Go 1.19

2022-11-17 12:57:17 -05:00

README.md

Update README.md

2020-12-01 16:48:41 -08:00

README.md

kustomize plugins

This directory holds kustomize plugins, each in its own sub-directory.

Directories

builtin

These are plugins written as Go plugins.

They are converted to statically linked code in the kustomize binary by a code generator (pluginator) at kustomize build time.

They are maintained as part of kustomize.
someteam.example.com/v1

Example plugins, maintained and tested by the kustomize maintainers, but not built-in to kustomize.

Some of these might get promoted to builtin someday, as happened with the Helm Chart Inflator.
untested/v1

Untested, unmaintained plugins.

These might be former examples that have been abandoned and may soon be deleted, or they might be WIP plugins that will someday become examples or builtins.

Testing

Regardless of the style used to write a plugin, it should be accompanied by a Go unit test, written using the framework maintained by the kustomize maintainers for just that purpose.

To see how this works, run any plugin test, e.g. this plugin written in bash:

pushd plugin/someteam.example.com/v1/bashedconfigmap
go test -v .
popd

For plugins with many tests, it's possible to target just one test:

pushd plugin/builtin/patchstrategicmergetransformer
go test -v -run TestBadPatchStrategicMergeTransformer PatchStrategicMergeTransformer_test.go
popd

Plugin styles

For more discussion, see extending kustomize.

a bare executable

This can be anything, e.g. a shell script, a shell script that runs java in a JVM, or python in a python VM, etc. They accept a YAML stream of resources on stdin, and emit a YAML stream on stdout. They accept configuration data in a file specified as the first argument on their command line.

If the executable is written in Go, it can take advantage of the same libraries as the kustomize builtin plugins.
a KRM function

These are containerized executables, that are pickier about their input. Rather than accepting a YAML stream of k8s resources, they want one ResourceList object (with the resources in that list).
a Go plugin

These are built as shared object libraries. Like a Go program, they're written in an unimportable main package with its own go.mod file. Go plugins cannot be reliably distributed (see docs), and are meant only as a structured way to write a builtin plugin intended for distribution with kustomize.