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.