7 Commits (a978d4ee99048967895eb48a208e731e5b00a36f)

Author	SHA1	Message	Date
James Bardin	da252de1a0	add provider validation ... Add validation which was removed from the configload package, along with additional validation checks. The output is slightly different, as instead of validating whether the modules are allowed to have provider configurations, we validate the various combinations of provider structures themselves.	5 years ago
Martin Atkins	eed6b3c48b	configs: Emit a warning for backends in nested modules ... Terraform considers backend configurations only in the root module, so any declarations in child modules are entirely ignored. To avoid users mistakenly thinking that a root module backend configuration has taken effect, we'll now emit a warning about it. This is a warning rather than an error because it's reasonable to call a module that would normally be a root module instead as a child module when writing a wrapper module to handle integration testing.	6 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
James Bardin	8111050c66	ensure we record diagnostics from nested modules ... When loading nested modules, the child module diagnostics were dropped in the recursive function. This mean that the config from the submodules wasn't fully loaded, even though no errors were reported to the user. This caused further problems if the plan was stored in a plan file, when means only the partial configuration was stored for the subsequent apply operation, which would result in unexplained "Resource node has no configuration attached" errors later on. Also due to the child module diagnostics being lost, any newly added nested modules would be silently ignored until `init` was run again manually.	7 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Martin Atkins	72ad927c4d	configs/configload: package for loading configurations ... Previously the behavior for loading and installing modules was included in the same package as the representation of the module tree (in the config/module package). In our new world, the model of a module tree (now called a "Config") is included in "configs" along with the Module and File structs. This new package replaces the loading and installation functionality previously in config/module with new equivalents that work with the model objects in "configs". As of this commit, only the loading functionality is implemented. The installation functionality will follow in subsequent commits.	8 years ago
Martin Atkins	8929eca405	configs: BuildConfig function ... BuildConfig creates a module tree by recursively walking through module calls in the root module and any descendent modules. This is intended to be used both for the simple case of loading already-installed modules and the more complex case of installing modules inside "terraform init", both of which will be dealt with in a separate package.	8 years ago