This PR intends to move the loader api to
internal. Only the necessary methods which
are needed for the api have been put into
`pkg/loader.go`.
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
This PR is an effort towards internalizing public APIs.
It moves some of the builtinconstants to internal/
Signed-off-by: Varsha Prasad Narsing <varshaprasad96@gmail.com>
* 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>
* fix containerized function mounts issue
* skip path test on windows
* move test out of temp dir
* update tests to deal with new working dir restrictions
* code review
* add origin annotation for resources generated by builtin and custom generators
* decouple origin data from generator data and account for inline generators
* Refactor prefix filter into its own filter, decoupled from the prefixsuffix filter
* Refactor prefix transformer into its own transformer, decoupled from the prefixsuffix transformer
* Refactor suffix filter into its own filter, decoupled from the prefixsuffix filter
* Refactor suffix transformer into its own transformer, decoupled from the prefixsuffix transformer
* Add a default nameSuffix field spec in addition to the namePrefix
* Remove the PrefixSuffixTransformer from the list of builtin transformers
* Add a multi-transformer to builtinhelpers.TransformFactories
* Remove the implementation of the prefixsuffixtransformer.PrefixSuffixTransformer
* Resolve style and format related feedback from the pull request
* Add test to test the legacy PrefixSuffixTransformer for BC purposes
* exec function working dir is the kustomization that referenced it
* suggested changes
* more code review
* use a field instead of an annotation
* more code review
* Move api/filesys to kyaml/filesys
* Add deprecated version of api/filesys with aliases to new code
* Use new kyaml/filesys package and update dependencies
* Migrate to kyaml/filesys and update dependencies
* Skip tests that break on Windows
This PR
- defines a patch conflict detector interface,
- extracts implementations of the interface from the
merginator code, making the merginator code
independent of --enable_kyaml.
- injects those implementations into kustomize
as a function of --enable_kyaml.
So, instead of using different merginators to combine
resmaps, this pr allows the use of a single patch merge
code path that uses different conflict detectors.
So instead of debating how to merge, we're now only
considering whether to warn on conflict detection
in one transformer.
This PR is in service of #3304, eliminating seven
instances where --enable_kyaml was consulted. These
were cases where conflict detection wasn't an issue
(but merging patches was).
