Hitting hard step limit of 10m
Increasing timeout field in cloudbuild.yaml past 10m seems to have no effect.
Maybe break goreleaser step into multiple substeps?
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/...
```
