16 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
Martin Atkins	0bbbb9c64b	configs: Experimental support for optional object type attributes ... This builds on an experimental feature in the underlying cty library which allows marking specific attribtues of an object type constraint as optional, which in turn modifies how the cty conversion package handles missing attributes in a source value: it will silently substitute a null value of the appropriate type rather than returning an error. In order to implement the experiment this commit temporarily forks the HCL typeexpr extension package into a local internal/typeexpr package, where I've extended the type constraint syntax to allow annotating object type attributes as being optional using the HCL function call syntax. If the experiment is successful -- both at the Terraform layer and in the underlying cty library -- we'll likely send these modifications to upstream HCL so that other HCL-based languages can potentially benefit from this new capability. Because it's experimental, the optional attribute modifier is allowed only with an explicit opt-in to the module_variable_optional_attrs experiment.	6 years ago
Pam Selle	bc57c20d10	Remove sensitive_variables experiment ... Ahead of the beta, remove the sensitive_variable experiment and update tests accordingly	6 years ago
Alisdair McDiarmid	13ed5af5c8	configs: Deprecate nested redundant interpolations ... Previous deprecations only included direct assignment of template-only expressions to arguments. That is, this was not deprecated: locals { foo = ["${var.foo}"] } This commit uses hclsyntax.VisitAll to detect and show deprecations for all template-only expressions, no matter how deep they are in a given expression.	6 years ago
Alisdair McDiarmid	803c95e552	Merge pull request #26105 from hashicorp/alisdair/more-interpolation-only-expression-deprecations ... configs: More interpolation-only expr deprecations	6 years ago
Pam Selle	81a6cde3cf	Merge pull request #26203 from hashicorp/pselle/deprecate-vendor-provisioners ... Deprecate vendor (3rd party) provisioners	6 years ago
Pam Selle	02c1bddfe1	Create experiment for sensitive attribute	6 years ago
Alisdair McDiarmid	e693c14e5a	configs: More interpolation-only expr deprecations ... Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.	6 years ago
Pam Selle	edc670d079	Add deprecation warning for vendor provisioners ... Adds a warning for chef, habitat, puppet, and salt-masterless provisioners, and a corresponding test file to test for the warning	6 years ago
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
James Bardin	84d1f5c688	convert destroy provisioner warnings to errors	6 years ago
James Bardin	35107acc46	allow "terraform" in destroy provisioners ... The values supplied in terraform are static, and do not create any dependencies.	6 years ago
James Bardin	c376905adc	it's safe for destroy provisioners to access path ... The path values are statically loaded, and do not create any dependencies that could cause problems with destroy provisioners.	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
James Bardin	8547603ff5	deprecation warning for destroy provisioner refs ... Add deprecation warning for references from destroy provisioners or their connections to external resources or values. In order to ensure resource destruction can be completed correctly, destroy nodes must be able to evaluate with only their instance state. We have sufficient information to validate destroy-time provisioners early on during the config loading process. Later on these can be converted to hard errors, and only allow self, count.index, and each.key in destroy provisioners. Limited the provisioner and block evaluation scope later on is tricky, but if the references can never be loaded, then they will never be encountered during evaluation.	6 years ago
Martin Atkins	91752f02da	configs: Warn for deprecated interpolation and quoted type constraints ... Following on from de652e22a2, this introduces deprecation warnings for when an attribute value expression is a template with only a single interpolation sequence, and for variable type constraints given in quotes. As with the previous commit, we allowed these deprecated forms with no warning for a few releases after v0.12.0 to ensure that folks who need to write cross-compatible modules for a while during upgrading would be able to do so, but we're now marking these as explicitly deprecated to guide users towards the new idiomatic forms. The "terraform 0.12upgrade" tool would've already updated configurations to not hit these warnings for those who had pre-existing configurations written for Terraform 0.11. The main target audience for these warnings are newcomers to Terraform who are learning from existing examples already published in various spots on the wider internet that may be showing older Terraform syntax, since those folks will not be running their configurations through the upgrade tool. These warnings will hopefully guide them towards modern Terraform usage during their initial experimentation, and thus reduce the chances of inadvertently adopting the less-readable legacy usage patterns in greenfield projects.	7 years ago
Martin Atkins	79dc808614	configs: Emit warnings for deprecated quoted references/keywords ... Terraform 0.12.0 removed the need for putting references and keywords in quotes, but we disabled the deprecation warnings for the initial release in order to avoid creating noise for folks who were intentionally attempting to maintain modules that were cross-compatible with both Terraform 0.11 and Terraform 0.12. However, with Terraform 0.12 now more widely used, the lack of these warnings seems to be causing newcomers to copy the quoted versions from existing examples on the internet, which is perpetuating the old and confusing quoted form in newer configurations. In preparation for phasing out these deprecated forms altogether in a future major release, and for the shorter-term benefit of giving better feedback to newcomers when they are learning from outdated examples, we'll now re-enable those deprecation warnings, and be explicit that the old forms are intended for removal in a future release. In order to properly test this, we establish a new set of test configurations that explicitly mark which warnings they are expecting and verify that they do indeed produce those expected warnings. We also verify that the "success" tests do _not_ produce warnings, while removing the ones that were previously written to succeed but have their warnings ignored.	7 years ago