14 Commits (df65de6945ddf6df2fb8d75cef719eeefed7944f)

Author	SHA1	Message	Date
James Bardin	37e60cd883	fix comment text	6 years ago
James Bardin	84d1f5c688	convert destroy provisioner warnings to errors	6 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
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	7 years ago
Thayne McCombs	7c678d104f	Add support for for_each for data blocks. ... This also fixes a few things with resource for_each: It makes validation more like validation for count. It makes sure the index is stored in the state properly.	7 years ago
Pam Selle	7d905f6777	Resource for_each	7 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Radek Simko	501fcd1e21	Fix tests after upgrading hcl	8 years ago
Martin Atkins	5661ab5991	configs: allow full type constraints for variables ... Previously we just ported over the simple "string", "list", and "map" type hint keywords from the old loader, which exist primarily as hints to the CLI for whether to treat -var=... arguments and environment variables as literal strings or as HCL expressions. However, we've been requested before to allow more specific constraints here because it's generally better UX for a type error to be detected within an expression in a calling "module" block rather than at some point deep inside a third-party module. To allow for more specific constraints, here we use the type constraint expression syntax defined as an extension within HCL, which uses the variable and function call syntaxes to represent types rather than values, like this: - string - number - bool - list(string) - list(any) - list(map(string)) - object({id=string,name=string}) In native HCL syntax this looks like: variable "foo" { type = map(string) } In JSON, this looks like: { "variable": { "foo": { "type": "map(string)" } } } The selection of literal processing or HCL parsing of CLI-set values is now explicit in the model and separate from the type, though it's still derived from the type constraint and thus not directly controllable in configuration. Since this syntax is more complex than the keywords that replaced it, for now the simpler keywords are still supported and "list" and "map" are interpreted as list(any) and map(any) respectively, mimicking how they were interpreted by Terraform 0.11 and earlier. For the time being our documentation should continue to recommend these shorthand versions until we gain more experience with the more-specific type constraints; most users should just make use of the additional primitive type constraints this enables: bool and number. As a result of these more-complete type constraints, we can now type-check the default value at config load time, which has the nice side-effect of allowing us to produce a tailored error message if an override file produces an invalid situation; previously the result was rather confusing because the error message referred to the original definition of the variable and not the overridden parts.	8 years ago
Martin Atkins	c05a1050fc	configs: Disable deprecation warning for quoted keywords/references ... Although we do still consider these deprecated for 0.12, we'll defer actually generating warnings for them until a later minor release so that module authors can retain their quoted identifiers for a period after 0.12 release for backward-compatibility with Terraform 0.11.	8 years ago
Martin Atkins	4fa8c16ead	configs: support ignore_changes wildcards ... The initial pass of implementation here missed the special case where ignore_changes can, in the old parser, be set to ["*"] to ignore changes to all attributes. Since that syntax is awkward and non-obvious, our new decoder will instead expect ignore_changes = all, using HCL2's capability to interpret an expression as a literal keyword. For compatibility with old configurations we will still accept the ["*"] form but emit a deprecation warning to encourage moving to the new form.	8 years ago
Martin Atkins	36fb5b52e7	configs: quoted keywords/references are warnings, not errors ... In our new loader we are changing certain values in configuration to be naked keywords or references rather than quoted strings as before. Since many of these have been shown in books, tutorials, and our own documentation we will make the old forms generate deprecation warnings rather than errors so that newcomers starting from older documentation can be eased into the new syntax, rather than getting blocked. This will also avoid creating a hard compatibility wall for reusable modules that are already published, allowing them to still be used in spite of these warnings and then fixed when the maintainer is able.	8 years ago
Martin Atkins	9be399d49c	configs: Another simple test for _invalid_ config files ... Much like TestParserLoadConfigFileSuccess, this is intended to be an easy-to-maintain collection of bad examples to test different permutations of our error handling. As with TestParserLoadConfigFileSuccess, we should also have more specific tests alongside this that check that the error outcome is what was expected, since this test just accepts any error and may thus not be testing what we think it is.	8 years ago
Martin Atkins	e524d1eb95	configs: Simple test of loading valid configuration files ... This test is intended to be an easy-to-maintain catalog of good examples that we can use to catch certain parsing or decoding regressions easily. It's not a fully-comprehensive test since it doesn't check the result of decoding, instead just accepting any decode that completes without errors. However, an easy-to-maintain test like this is a good complement to some more specialized tests since we can easily collect good examples over time and just add them in here.	8 years ago