mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-07-01 02:11:20 +00:00
b9f05dd357
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/... ```
55 lines
1.3 KiB
Go
55 lines
1.3 KiB
Go
// Copyright 2019 The Kubernetes Authors.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
package build
|
|
|
|
import (
|
|
"testing"
|
|
|
|
"sigs.k8s.io/kustomize/api/filesys"
|
|
"sigs.k8s.io/kustomize/api/konfig"
|
|
)
|
|
|
|
func TestNewOptionsToSilenceCodeInspectionError(t *testing.T) {
|
|
if NewOptions("foo", "bar") == nil {
|
|
t.Fatal("could not make new options")
|
|
}
|
|
}
|
|
|
|
func TestBuildValidate(t *testing.T) {
|
|
var cases = []struct {
|
|
name string
|
|
args []string
|
|
path string
|
|
erMsg string
|
|
}{
|
|
{"noargs", []string{}, filesys.SelfDir, ""},
|
|
{"file", []string{"beans"}, "beans", ""},
|
|
{"path", []string{"a/b/c"}, "a/b/c", ""},
|
|
{"path", []string{"too", "many"},
|
|
"",
|
|
"specify one path to " +
|
|
konfig.DefaultKustomizationFileName()},
|
|
}
|
|
for _, mycase := range cases {
|
|
opts := Options{}
|
|
e := opts.Validate(mycase.args)
|
|
if len(mycase.erMsg) > 0 {
|
|
if e == nil {
|
|
t.Errorf("%s: Expected an error %v", mycase.name, mycase.erMsg)
|
|
}
|
|
if e.Error() != mycase.erMsg {
|
|
t.Errorf("%s: Expected error %s, but got %v", mycase.name, mycase.erMsg, e)
|
|
}
|
|
continue
|
|
}
|
|
if e != nil {
|
|
t.Errorf("%s: unknown error: %v", mycase.name, e)
|
|
continue
|
|
}
|
|
if opts.kustomizationPath != mycase.path {
|
|
t.Errorf("%s: expected path '%s', got '%s'", mycase.name, mycase.path, opts.kustomizationPath)
|
|
}
|
|
}
|
|
}
|