9 Commits (6cc3e1d0bd635cdae92b3e0055c19d86dfa7a222)

Author	SHA1	Message	Date
Martin Atkins	86c02d5c35	command: "terraform init" can partially initialize for 0.12upgrade ... There are a few constructs from 0.11 and prior that cause 0.12 parsing to fail altogether, which previously created a chicken/egg problem because we need to install the providers in order to run "terraform 0.12upgrade" and thus fix the problem. This changes "terraform init" to use the new "early configuration" loader for module and provider installation. This is built on the more permissive parser in the terraform-config-inspect package, and so it allows us to read out the top-level blocks from the configuration while accepting legacy HCL syntax. In the long run this will let us do version compatibility detection before attempting a "real" config load, giving us better error messages for any future syntax additions, but in the short term the key thing is that it allows us to install the dependencies even if the configuration isn't fully valid. Because backend init still requires full configuration, this introduces a new mode of terraform init where it detects heuristically if it seems like we need to do a configuration upgrade and does a partial init if so, before finally directing the user to run "terraform 0.12upgrade" before running any other commands. The heuristic here is based on two assumptions: - If the "early" loader finds no errors but the normal loader does, the configuration is likely to be valid for Terraform 0.11 but not 0.12. - If there's already a version constraint in the configuration that excludes Terraform versions prior to v0.12 then the configuration is probably _already_ upgraded and so it's just a normal syntax error, even if the early loader didn't detect it. Once the upgrade process is removed in 0.13.0 (users will be required to go stepwise 0.11 -> 0.12 -> 0.13 to upgrade after that), some of this can be simplified to remove that special mode, but the idea of doing the dependency version checks against the liberal parser will remain valuable to increase our chances of reporting version-based incompatibilities rather than syntax errors as we add new features in future.	7 years ago
Martin Atkins	0c0a437bcb	Move module install functionality over to internal/initwd	7 years ago
Martin Atkins	30b7040e95	core: Validate module references ... Previously we were making an invalid assumption in evaluating module call references (like module.foo) that the module must exist, which is incorrect for that particular case because it's a reference to a child module, not to an object within the current module. However, now that we have the mechanism for static validation of references, we'll deal with this one there so it can be caught sooner. That then makes the original assumption valid, though for a different reason. This is verified by two new context tests for validation: - TestContext2Validate_invalidModuleRef - TestContext2Validate_invalidModuleOutputRef	8 years ago
Martin Atkins	3b49028b77	core: Static-validate resource references against schemas ... In the initial move to HCL2 we started relying only on full expression evaluation to catch attribute errors, but that's not sufficient for resource attributes in practice because during validation we can't know yet whether a resource reference evaluates to a single object or to a list of objects (if count is set). To address this, here we reinstate some static validation of resource references by analyzing directly the reference objects, disregarding any instance index if present, and produce errors if the remaining subsequent traversal steps do not correspond to items within the resource type schema. This also allows us to produce some more specialized error messages for certain situations. In particular, we can recognize a reference like aws_instance.foo.count, which in 0.11 and prior was a weird special case for determining the count value of a resource block, and offer a helpful error showing the new length(aws_instance.foo) usage pattern. This eventually delegates to the static traversal validation logic that was added to the configschema package in a previous commit, which also includes some specialized error messages that distinguish between attributes and block types in the schema so that the errors relate more directly to constructs the user can see in the configuration. In future we could potentially move more of the checks from the dynamic schema construction step to the static validation step, but resources are the reference type that most needs this immediately due to the ambiguity caused by the instance indexing syntax. We can safely refactor other reference types to be statically validated in later releases. This is verified by two pre-existing context validate tests which we temporarily disabled during earlier work (now re-enabled) and also by a new validate test aimed specifically at the special case for the "count" attribute.	8 years ago
Martin Atkins	ece8b6e734	repl: Fix tests ... The test suite was not updated to deal with the new assumptions of the HCL2-based expression evaluator, which requires configuration to exist as well as state. Therefore we add a simple configuration fixture to have it validate expressions against. This also includes updates to expect the different error messages that the new evaluator produces.	8 years ago
Martin Atkins	9bc153e809	repl: Make full logging optional in tests ... Logs will be hidden unless verbose mode is enabled on the test run.	8 years ago
Martin Atkins	5ff35c1a9a	repl: Make tests compile and execute without panics ... There are still some errors left, because our expression evaluator now does more validation than before and so we'll need to (in a subsequent commit) actually use a fixture configuration for these tests so that the validations will allow the expressions to be validated.	8 years ago
Mitchell Hashimoto	a633cdf95d	terraform: improve error messages to assist REPL	10 years ago
Mitchell Hashimoto	d9c522173d	repl: package for TF REPL	10 years ago