terraform

Commit Graph

Author	SHA1	Message	Date
Martin Atkins	d1bc412220	configs: Custom variable validation is no longer experimental All of the feedback from the experiment described enhancements that can potentially be added later without breaking changes, so this change simply removes the experiment gate from the feature as originally implemented with no changes to its functionality. Further enhancements may follow in later releases, but the goal of this change is just to ship the feature exactly as it was under the experiment. Most of the changes here are cleaning up the experiment opt-ins from our test cases. The most important parts are in configs/experiments.go and in experiments/experiment.go .	6 years ago
Martin Atkins	ff4ea042c2	config: Allow module authors to specify validation rules for variables The existing "type" argument allows specifying a type constraint that allows for some basic validation, but often there are more constraints on a variable value than just its type. This new feature (requiring an experiment opt-in for now, while we refine it) allows specifying arbitrary validation rules for any variable which can then cause custom error messages to be returned when a caller provides an inappropriate value. variable "example" { validation { condition = var.example != "nope" error_message = "Example value must not be \"nope\"." } } The core parts of this are designed to do as little new work as possible when no validations are specified, and thus the main new checking codepath here can therefore only run when the experiment is enabled in order to permit having validations.	6 years ago
Martin Atkins	02576988c1	lang: "try" and "can" functions These are intended to make it easier to work with arbitrary data structures whose shape might not be known statically, such as the result of jsondecode(...) or yamldecode(...) of data from a separate system. For example, in an object value which has attributes that may or may not be set we can concisely provide a fallback value to use when the attribute isn't set: try(local.example.foo, "fallback-foo") Using a "try to evaluate" model rather than explicit testing fits better with the usual programming model of the Terraform language where values are normally automatically converted to the necessary type where possible: the given expression is subject to all of the same normal type conversions, which avoids inadvertently creating a more restrictive evaluation model as might happen if this were handled using checks like a hypothetical isobject(...) function, etc.	6 years ago

Author

SHA1

Message

Date

Martin Atkins

d1bc412220

configs: Custom variable validation is no longer experimental

All of the feedback from the experiment described enhancements that can
potentially be added later without breaking changes, so this change simply
removes the experiment gate from the feature as originally implemented
with no changes to its functionality.

Further enhancements may follow in later releases, but the goal of this
change is just to ship the feature exactly as it was under the experiment.

Most of the changes here are cleaning up the experiment opt-ins from our
test cases. The most important parts are in configs/experiments.go and in
experiments/experiment.go .

Martin Atkins

ff4ea042c2

config: Allow module authors to specify validation rules for variables

The existing "type" argument allows specifying a type constraint that
allows for some basic validation, but often there are more constraints on
a variable value than just its type.

This new feature (requiring an experiment opt-in for now, while we refine
it) allows specifying arbitrary validation rules for any variable which
can then cause custom error messages to be returned when a caller provides
an inappropriate value.

    variable "example" {
      validation {
        condition = var.example != "nope"
        error_message = "Example value must not be \"nope\"."
      }
    }

The core parts of this are designed to do as little new work as possible
when no validations are specified, and thus the main new checking codepath
here can therefore only run when the experiment is enabled in order to
permit having validations.

Martin Atkins

02576988c1

lang: "try" and "can" functions

These are intended to make it easier to work with arbitrary data
structures whose shape might not be known statically, such as the result
of jsondecode(...) or yamldecode(...) of data from a separate system.

For example, in an object value which has attributes that may or may not
be set we can concisely provide a fallback value to use when the attribute
isn't set:

    try(local.example.foo, "fallback-foo")

Using a "try to evaluate" model rather than explicit testing fits better
with the usual programming model of the Terraform language where values
are normally automatically converted to the necessary type where possible:
the given expression is subject to all of the same normal type conversions,
which avoids inadvertently creating a more restrictive evaluation model
as might happen if this were handled using checks like a hypothetical
isobject(...) function, etc.

3 Commits (211edf5d7545bcb5cd741bad6145ccc4e261bcd3)