config

Overview ¶

Package config simplifies the declaration of configuration options. Right now the implementation maps them directly to command line flags. When combined with test/e2e/framework/viperconfig in a test suite, those flags then can also be read from a config file.

The command line flags all get stored in a private flag set. The developer of the E2E test suite decides how they are exposed. Options include:

• exposing as normal flags in the actual command line: CopyFlags(Flags, flag.CommandLine)
• populate via test/e2e/framework/viperconfig: viperconfig.ViperizeFlags("my-config.yaml", "", Flags)
• a combination of both: CopyFlags(Flags, flag.CommandLine) viperconfig.ViperizeFlags("my-config.yaml", "", flag.CommandLine)

Instead of defining flags one-by-one, test developers annotate a structure with tags and then call a single function. This is the same approach as in https://godoc.org/github.com/jessevdk/go-flags, but implemented so that a test suite can continue to use the normal "flag" package.

For example, a file storage/csi.go might define:

var scaling struct {
        NumNodes int  `default:"1" description:"number of nodes to run on"`
        Master string
}
_ = config.AddOptions(&scaling, "storage.csi.scaling")

This defines the following command line flags:

-storage.csi.scaling.numNodes=<int>  - number of nodes to run on (default: 1)
-storage.csi.scaling.master=<string>

All fields in the structure must be exported and have one of the following types (same as in the `flag` package): - bool - time.Duration - float64 - string - int - int64 - uint - uint64 - and/or nested or embedded structures containing those basic types.

Each basic entry may have a tag with these optional keys:

usage:   additional explanation of the option
default: the default value, in the same format as it would
         be given on the command line and true/false for
         a boolean

The names of the final configuration options are a combination of an optional common prefix for all options in the structure and the name of the fields, concatenated with a dot. To get names that are consistent with the command line flags defined by `ginkgo`, the initial character of each field name is converted to lower case.

There is currently no support for aliases, so renaming the fields or the common prefix will be visible to users of the test suite and may breaks scripts which use the old names.

The variable will be filled with the actual values by the test suite before running tests. Beware that the code which registers Ginkgo tests cannot use those config options, because registering tests and options both run before the E2E test suite handles parameters.