2 Commits (bf91bff2c896180b4e873576aa0d9ecd276feb2e)

Author	SHA1	Message	Date
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