* 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>
* install_kustomize: support linux/aarch64, with fallback to old behavior
* shellcheck
* Comments from first review
* Comments from review
* Review comments: message consistency
* 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
'go get/install' will install binaries into GOBIN when it's set which is not
always same with GOPATH/bin
Fix below error:
$ hack/testExamplesAgainstKustomize.sh HEAD
Installing kustomize HEAD
On linux, and not on remote CI. Running expensive tests.
make: Nothing to be done for '/home/lizj/gosrc/bin/helm'.
Removing kustomize HEAD
rm: cannot remove '/home/lizj/gosrc/bin/kustomize': No such file or directory
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
The PR exposes some of the top level kustomize commands
(especially `build`) for reuse in other command line tools
(expecially `kubectl`, see #1500).
This PR represents option 3 from the following list of ways
this exposure could be arranged.
1. Expose the commands in the `api` module.
```
REPO/api/go.mod
REPO/api/builtins
REPO/api/commands <- new
REPO/api/...
```
Disadvantage: This would make `api` module depend on cobra.
That's bad for clients that want to depend on the api, but
want to write their own commands at their own version of
cobra. The `api` module shouldn't depend on UX libraries
like cobra.
2. Expose the commands in their own `commands` module.
They'd appear alongside `api`, e.g. `
```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/commands/go.mod
REPO/commands/build
REPO/commands/edit
REPO/commands/...
```
Advantage: The commands would be consumed by the kustomize
binary and the kubectl binary in the same way.
Disadvantage: The kustomize binary module and the commands
module could evolve separately with their own version
numbers, creating confusion.
3. Expose the commands in the existing `kustomize` module
```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/kustomize/go.mod
REPO/kustomize/main.go
REPO/kustomize/commands/build
REPO/kustomize/commands/edit
REPO/kustomize/commands/...
```
Outside users, e.g. kubectl, could then
```
import sigs.k8s.io/kustomize/kustomize/v3/commands/build
```
and hopefully still get the `main` package
as they do now via:
```
go get sigs.k8s.io/kustomize/kustomize/v3
```
Advantage: 1) The kustomize binary ships at the same version
as the commands - which makes sense as the binary's
_version_ refers to how the CLI operates (command names,
flags, etc.). This makes it easy to related the version of
a kustomize binary with the version of commands running in
some other CLI binary. 2) The path to the kustomize binary
doesn't change.
Disadvantage: It's an atypical Go module arrangement.
Usually `main` packages live as leaves under a directory
called `cmd` inside a module, rather than at the _top_ of
the module. This might cause some problems. If so, we can
go with option 4.
4. Same as 3, but move `main.go` (the `main` package) down one step.
```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/kustomize/go.mod
REPO/kustomize/cmd/main.go
REPO/kustomize/commands/build
REPO/kustomize/commands/edit
REPO/kustomize/commands/...
```
This is important to improve reliency of other automations/scripts that are using this script internally. Otherwise install script might stall forever in some cases.
