mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-06-30 09:51:23 +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/... ```
45 lines
927 B
Go
45 lines
927 B
Go
// Copyright 2019 The Kubernetes Authors.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
package fix
|
|
|
|
import (
|
|
"github.com/spf13/cobra"
|
|
"sigs.k8s.io/kustomize/api/filesys"
|
|
"sigs.k8s.io/kustomize/kustomize/v3/commands/internal/kustfile"
|
|
)
|
|
|
|
// NewCmdFix returns an instance of 'fix' subcommand.
|
|
func NewCmdFix(fSys filesys.FileSystem) *cobra.Command {
|
|
cmd := &cobra.Command{
|
|
Use: "fix",
|
|
Short: "Fix the missing fields in kustomization file",
|
|
Long: "",
|
|
Example: `
|
|
# Fix the missing and deprecated fields in kustomization file
|
|
kustomize edit fix
|
|
|
|
`,
|
|
RunE: func(cmd *cobra.Command, args []string) error {
|
|
return RunFix(fSys)
|
|
},
|
|
}
|
|
return cmd
|
|
}
|
|
|
|
// RunFix runs `fix` command
|
|
func RunFix(fSys filesys.FileSystem) error {
|
|
mf, err := kustfile.NewKustomizationFile(fSys)
|
|
if err != nil {
|
|
return err
|
|
}
|
|
|
|
m, err := mf.Read()
|
|
if err != nil {
|
|
return err
|
|
}
|
|
|
|
m.FixKustomizationPreMarshalling()
|
|
return mf.Write(m)
|
|
}
|