You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CLI commands are located under `internal/cmd`, where each folder includes the source code for a `group` of commands. Inside `pkg` you can find several useful packages that are shared by the commands and provide additional functionality such as `flags`, `globalflags`, `tables`, etc.
21
-
22
-
### Getting started
23
-
24
-
Check the [Authentication](README.md#authentication) section on the README.
25
-
26
-
#### Useful Make commands
25
+
### Useful Make commands
27
26
28
27
These commands can be executed from the project root:
29
28
@@ -33,7 +32,214 @@ These commands can be executed from the project root:
33
32
-`make generate-docs`: generate Markdown documentation for every command
34
33
-`make test`: run unit tests
35
34
36
-
#### Local development
35
+
### Repository structure
36
+
37
+
The CLI commands are located under `internal/cmd`, where each folder includes the source code for each subcommand (including their own subcommands). Inside `pkg` you can find several useful packages that are shared by the commands and provide additional functionality such as `flags`, `globalflags`, `tables`, etc.
38
+
39
+
### Implementing a new command
40
+
41
+
Let's suppose you want to want to implement a new command `bar`, that would be the direct child of an existing command `stackit foo` (meaning it would be invoked as `stackit foo bar`):
42
+
43
+
1. You would start by creating a new folder `bar/` inside `internal/cmd/foo/`
44
+
2. Following with the creation of a file `bar.go` inside your new folder `internal/cmd/foo/bar/`
45
+
1. The Go package should be similar to the command usage, in this case `package bar` would be an adequate name
46
+
2. Please refer to the [Command file structure](./CONTRIBUTION.md/#command-file-structure) section for details on the strcutre of the file itself
47
+
3. To register the command `bar` as a child of the existing command `foo`, add `cmd.AddCommand(bar.NewCmd(p))` to the `addSubcommands` method of the constructor of the `foo` command
48
+
1. In this case, `p` is the `printer` that is passed from the root command to all subcommands of the tree (refer to the [Outputs, prints and debug logs](./CONTRIBUTION.md/#outputs-prints-and-debug-logs) section for more details regarding the `printer`)
49
+
50
+
Please remeber to run `make generate-docs` after your changes to keep the commands' documentation updated.
51
+
52
+
#### Command file structure
53
+
54
+
Below is a typical structure of a CLI command:
55
+
56
+
```go
57
+
package bar
58
+
59
+
import (
60
+
(...)
61
+
)
62
+
63
+
// Define consts for command flags
64
+
const (
65
+
someArg = "MY_ARG"
66
+
someFlag = "my-flag"
67
+
)
68
+
69
+
// Struct to model user input (arguments and/or flags)
70
+
type inputModel struct {
71
+
*globalflags.GlobalFlagModel
72
+
MyArgstring
73
+
MyFlag *string
74
+
}
75
+
76
+
// "bar" command constructor
77
+
funcNewCmd() *cobra.Command {
78
+
cmd:= &cobra.Command{
79
+
Use: "bar",
80
+
Short: "Short description of the command (is shown in the help of parent command)",
81
+
Long: "Long description of the command. Can contain some more information about the command usage. It is shown in the help of the current command.",
82
+
Args: args.SingleArg(someArg, utils.ValidateUUID), // Validate argument, with an optional validation function
83
+
Example: examples.Build(
84
+
examples.NewExample(
85
+
`Do something with command "bar"`,
86
+
"$ stackit foo bar arg-value --my-flag flag-value"),
Please remeber to always add unit tests for `parseInput`, `buildRequest` (in `bar_test.go`), and any other util functions used.
181
+
182
+
If the new command `bar` is the first command in the CLI using a STACKIT service `foo`, please refer to [Onboarding a new STACKIT service](./CONTRIBUTION.md/#onboarding-a-new-stackit-service).
183
+
184
+
#### Outputs, prints and debug logs
185
+
186
+
The CLI has 4 different verbosity levels:
187
+
188
+
-`error`: For only displaying errors
189
+
-`warning`: For displaying user facing warnings _(and all of the above)_
190
+
-`info` (default): For displaying user facing info, such as operation success messages and spinners _(and all of the above)_
191
+
-`debug`: For displaying structured logs with different levels, including errors _(and all of the above)_
192
+
193
+
For prints that are specific to a certain log level, you can use the methods defined in the `print` package: `Error`, `Warn`, `Info`, and `Debug`.
194
+
195
+
For command outputs that should always be displayed, no matter the defined verbosity, you should use the `print` methods `Outputf` and `Outputln`. These should only be used for the actual output of the commands, which can usually be described by "I ran the command to see _this_".
196
+
197
+
### Onboarding a new STACKIT service
198
+
199
+
If you want to add a command that uses a STACKIT service `foo` that was not yet used by the CLI, you will first need to implement a few extra steps to configure the new service:
200
+
201
+
1. Add a `FooCustomEndpointKey` key in `internal/pkg/config/config.go` (and add it to `ConfigKeys` and set the to default to `""` using `viper.SetDefault`)
202
+
2. Update the `stackit config unset` and `stackit config unset` commands by adding flags to set and unset a custom endpoint for the `foo` service API, respectively, and update their unit tests
203
+
3. Setup the SDK client configuration, using the authentication method configured in the CLI
204
+
205
+
1. This is done in `internal/pkg/services/foo/client/client.go`
206
+
2. Below is an example of a typical `client.go` file structure:
0 commit comments