* 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.
