4 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)

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
Alisdair McDiarmid	7ca7b1f0fe	configs: Simplify required_providers blocks ... We now permit at most one `required_providers` block per module (except for overrides). This prevents users (and Terraform) from struggling to understand how to merge multiple `required_providers` configurations, with `version` and `source` attributes split across multiple blocks. Because only one `required_providers` block is permitted, there is no need to concatenate version constraints and resolve them. This allows us to simplify the structs used to represent provider requirements, aligning more closely with other structs in this package. This commit also fixes a semantic use-before-initialize bug, where resources defined before a `required_providers` block would be unable to use its source attribute. We achieve this by processing the module's `required_providers` configuration (and overrides) before resources. Overrides for `required_providers` work as before, replacing the entire block per provider.	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
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago