configs: Hint for a misplaced top-level required_providers block

With provider dependencies now appearing inside a nested block, it seems
likely that configuration examples showing dependencies out of context
will sometimes mislead users into thinking that required_providers is
toplevel.

To give better feedback in that situation, we'll produce a specialized
error in that case hinting the correct structure to the user.
This commit is contained in:
Martin Atkins 2020-04-03 15:01:57 -07:00
parent 297a3a5db9
commit 3e3d8f6764
2 changed files with 24 additions and 0 deletions

View File

@ -92,6 +92,15 @@ func (p *Parser) loadConfigFile(path string, override bool) (*File, hcl.Diagnost
}
}
case "required_providers":
// required_providers should be nested inside a "terraform" block
diags = append(diags, &hcl.Diagnostic{
Severity: hcl.DiagError,
Summary: "Invalid required_providers block",
Detail: "A \"required_providers\" block must be nested inside a \"terraform\" block.",
Subject: block.TypeRange.Ptr(),
})
case "provider":
cfg, cfgDiags := decodeProviderBlock(block)
diags = append(diags, cfgDiags...)
@ -193,6 +202,12 @@ var configFileSchema = &hcl.BodySchema{
{
Type: "terraform",
},
{
// This one is not really valid, but we include it here so we
// can create a specialized error message hinting the user to
// nest it inside a "terraform" block.
Type: "required_providers",
},
{
Type: "provider",
LabelNames: []string{"name"},

View File

@ -0,0 +1,9 @@
# A top-level required_providers block is not valid, but we have a specialized
# error for it to hint the user to move it into a terraform block.
required_providers { # ERROR: Invalid required_providers block
}
# This one is valid, and what the user should rewrite the above to be like.
terraform {
required_providers {}
}