7 Commits (a15a4acf2f0e4e8a749d9cb9a46ac09f224d5e90)

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