exec

type Action struct {
	// Exec is the exact command to execute.
	//
	// You may execute more than one command but must include the `shell` field
	// to indicate that the command should be run in a shell. It is best
	// practice, however, to simply use multiple `exec` specs instead of
	// executing multiple commands in a single shell call.
	Exec string `yaml:"exec"`
	// Shell is the specific shell to use in executing the command. If empty
	// (the default), no shell is used to execute the command and instead the
	// operating system's `exec` family of calls is used.
	Shell string `yaml:"shell,omitempty"`
	// VarStdout is a shortcut for Var:{VARIABLE_NAME}:from:stdout
	VarStdout string `yaml:"var-stdout,omitempty"`
	// VarStderr is a shortcut for Var:{VARIABLE_NAME}:from:stderr
	VarStderr string `yaml:"var-stderr,omitempty"`
	// VarRC is a shortcut for Var:{VARIABLE_NAME}:from:returncode
	VarRC string `yaml:"var-rc,omitempty"`
}

type Defaults struct {
	// contains filtered or unexported fields
}

type Expect struct {
	// ExitCode is the expected exit code for the executed command. The default
	// (0) is the universal successful exit code, so you only need to set this
	// if you expect a non-successful result from executing the command.
	ExitCode int `yaml:"exit-code,omitempty"`
	// Out has things that are expected in the stdout response
	Out *PipeExpect `yaml:"out,omitempty"`
	// Err has things that are expected in the stderr response
	Err *PipeExpect `yaml:"err,omitempty"`
}

type On struct {
	// Fail contains one or more actions to take if any of a Spec's assertions
	// fail.
	//
	// For example, if you wanted to grep a log file in the event that no
	// connectivity on a particular IP:PORT combination could be made you might
	// do this:
	//
	// “`yaml
	// tests:
	//  - exec: nc -z $HOST $PORT
	//    on:
	//      fail:
	//        exec: grep ERROR /var/log/myapp.log
	// “`
	//
	// The `grep ERROR /var/log/myapp.log` command will only be executed if
	// there is no connectivity to $HOST:$PORT and the results of that grep
	// will be directed to the test's output. You can use the `gdt.WithDebug()`
	// function to configure additional `io.Writer`s to direct this output to.
	Fail *Action `yaml:"fail,omitempty"`
}

type PipeExpect struct {
	// ContainsAll is one or more strings that *all* must be present in the
	// contents of the pipe
	ContainsAll *api.FlexStrings `yaml:"contains,omitempty"`
	// ContainsNone is one or more strings, *none of which* should be present in
	// the contents of the pipe
	ContainsNone *api.FlexStrings `yaml:"contains-none-of,omitempty"`
	// ContainsOneOf is one or more strings of which *at least one* must be
	// present in the contents of the pipe
	ContainsAny *api.FlexStrings `yaml:"contains-one-of,omitempty"`
}

type Spec struct {
	api.Spec
	Action
	// Assert is an object containing the conditions that the Spec will assert.
	Assert *Expect `yaml:"assert,omitempty"`
	// On is an object containing actions to take upon certain conditions.
	On *On `yaml:"on,omitempty"`
	// Var allows the test author to save arbitrary data to the test scenario,
	// facilitating the passing of variables between test specs potentially
	// provided by different gdt Plugins.
	Var Variables `yaml:"var,omitempty"`
}

type VarEntry struct {
	// From is a string that indicates where the value of the variable will be
	// sourced from. `stdout`, `stderr` and `returncode` indicate to source the
	// value of the variable from the output buffer for stdout, stderr or the
	// returncode value. All other strings indicate the value of the variable
	// should be sourced from an envvar of the same name.
	From string `yaml:"from"`
}

type Variables map[string]VarEntry