2024-02-08 03:48:59 -06:00
|
|
|
// Copyright (c) The OpenTofu Authors
|
|
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
// Copyright (c) 2023 HashiCorp, Inc.
|
2023-05-02 10:33:06 -05:00
|
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
package configs
|
|
|
|
|
|
|
|
import (
|
2019-09-09 17:58:44 -05:00
|
|
|
"github.com/hashicorp/hcl/v2"
|
2024-03-04 10:04:45 -06:00
|
|
|
"github.com/opentofu/opentofu/internal/encryption/config"
|
2018-02-02 19:22:25 -06:00
|
|
|
)
|
|
|
|
|
|
|
|
// LoadConfigFile reads the file at the given path and parses it as a config
|
|
|
|
// file.
|
|
|
|
//
|
|
|
|
// If the file cannot be read -- for example, if it does not exist -- then
|
|
|
|
// a nil *File will be returned along with error diagnostics. Callers may wish
|
|
|
|
// to disregard the returned diagnostics in this case and instead generate
|
|
|
|
// their own error message(s) with additional context.
|
|
|
|
//
|
|
|
|
// If the returned diagnostics has errors when a non-nil map is returned
|
|
|
|
// then the map may be incomplete but should be valid enough for careful
|
|
|
|
// static analysis.
|
|
|
|
//
|
|
|
|
// This method wraps LoadHCLFile, and so it inherits the syntax selection
|
|
|
|
// behaviors documented for that method.
|
|
|
|
func (p *Parser) LoadConfigFile(path string) (*File, hcl.Diagnostics) {
|
2018-02-06 20:05:14 -06:00
|
|
|
return p.loadConfigFile(path, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// LoadConfigFileOverride is the same as LoadConfigFile except that it relaxes
|
|
|
|
// certain required attribute constraints in order to interpret the given
|
|
|
|
// file as an overrides file.
|
|
|
|
func (p *Parser) LoadConfigFileOverride(path string) (*File, hcl.Diagnostics) {
|
|
|
|
return p.loadConfigFile(path, true)
|
|
|
|
}
|
|
|
|
|
2023-09-26 12:09:27 -05:00
|
|
|
// LoadTestFile reads the file at the given path and parses it as a OpenTofu
|
2023-06-22 10:03:37 -05:00
|
|
|
// test file.
|
|
|
|
//
|
|
|
|
// It references the same LoadHCLFile as LoadConfigFile, so inherits the same
|
|
|
|
// syntax selection behaviours.
|
|
|
|
func (p *Parser) LoadTestFile(path string) (*TestFile, hcl.Diagnostics) {
|
|
|
|
body, diags := p.LoadHCLFile(path)
|
|
|
|
if body == nil {
|
|
|
|
return nil, diags
|
|
|
|
}
|
|
|
|
|
|
|
|
test, testDiags := loadTestFile(body)
|
|
|
|
diags = append(diags, testDiags...)
|
|
|
|
return test, diags
|
|
|
|
}
|
|
|
|
|
2018-02-06 20:05:14 -06:00
|
|
|
func (p *Parser) loadConfigFile(path string, override bool) (*File, hcl.Diagnostics) {
|
2018-02-02 19:22:25 -06:00
|
|
|
body, diags := p.LoadHCLFile(path)
|
|
|
|
if body == nil {
|
|
|
|
return nil, diags
|
|
|
|
}
|
|
|
|
|
|
|
|
file := &File{}
|
|
|
|
|
|
|
|
var reqDiags hcl.Diagnostics
|
|
|
|
file.CoreVersionConstraints, reqDiags = sniffCoreVersionRequirements(body)
|
|
|
|
diags = append(diags, reqDiags...)
|
|
|
|
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
// We'll load the experiments first because other decoding logic in the
|
|
|
|
// loop below might depend on these experiments.
|
|
|
|
var expDiags hcl.Diagnostics
|
Experiments supported only in alpha/dev builds
We originally introduced the idea of language experiments as a way to get
early feedback on not-yet-proven feature ideas, ideally as part of the
initial exploration of the solution space rather than only after a
solution has become relatively clear.
Unfortunately, our tradeoff of making them available in normal releases
behind an explicit opt-in in order to make it easier to participate in the
feedback process had the unintended side-effect of making it feel okay
to use experiments in production and endure the warnings they generate.
This in turn has made us reluctant to make use of the experiments feature
lest experiments become de-facto production features which we then feel
compelled to preserve even though we aren't yet ready to graduate them
to stable features.
In an attempt to tweak that compromise, here we make the availability of
experiments _at all_ a build-time flag which will not be set by default,
and therefore experiments will not be available in most release builds.
The intent (not yet implemented in this PR) is for our release process to
set this flag only when it knows it's building an alpha release or a
development snapshot not destined for release at all, which will therefore
allow us to still use the alpha releases as a vehicle for giving feedback
participants access to a feature (without needing to install a Go
toolchain) but will not encourage pretending that these features are
production-ready before they graduate from experimental.
Only language experiments have an explicit framework for dealing with them
which outlives any particular experiment, so most of the changes here are
to that generalized mechanism. However, the intent is that non-language
experiments, such as experimental CLI commands, would also in future
check Meta.AllowExperimentalFeatures and gate the use of those experiments
too, so that we can be consistent that experimental features will never
be available unless you explicitly choose to use an alpha release or
a custom build from source code.
Since there are already some experiments active at the time of this commit
which were not previously subject to this restriction, we'll pragmatically
leave those as exceptions that will remain generally available for now,
and so this new approach will apply only to new experiments started in the
future. Once those experiments have all concluded, we will be left with
no more exceptions unless we explicitly choose to make an exception for
some reason we've not imagined yet.
It's important that we be able to write tests that rely on experiments
either being available or not being available, so here we're using our
typical approach of making "package main" deal with the global setting
that applies to Terraform CLI executables while making the layers below
all support fine-grain selection of this behavior so that tests with
different needs can run concurrently without trampling on one another.
As a compromise, the integration tests in the terraform package will
run with experiments enabled _by default_ since we commonly need to
exercise experiments in those tests, but they can selectively opt-out
if they need to by overriding the loader setting back to false again.
2022-04-27 13:14:51 -05:00
|
|
|
file.ActiveExperiments, expDiags = sniffActiveExperiments(body, p.allowExperiments)
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
diags = append(diags, expDiags...)
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
content, contentDiags := body.Content(configFileSchema)
|
|
|
|
diags = append(diags, contentDiags...)
|
|
|
|
|
|
|
|
for _, block := range content.Blocks {
|
|
|
|
switch block.Type {
|
|
|
|
|
|
|
|
case "terraform":
|
|
|
|
content, contentDiags := block.Body.Content(terraformBlockSchema)
|
|
|
|
diags = append(diags, contentDiags...)
|
|
|
|
|
2021-02-26 11:48:42 -06:00
|
|
|
// We ignore the "terraform_version", "language" and "experiments"
|
|
|
|
// attributes here because sniffCoreVersionRequirements and
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
// sniffActiveExperiments already dealt with those above.
|
2018-02-02 19:22:25 -06:00
|
|
|
|
|
|
|
for _, innerBlock := range content.Blocks {
|
|
|
|
switch innerBlock.Type {
|
|
|
|
|
|
|
|
case "backend":
|
|
|
|
backendCfg, cfgDiags := decodeBackendBlock(innerBlock)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if backendCfg != nil {
|
|
|
|
file.Backends = append(file.Backends, backendCfg)
|
|
|
|
}
|
|
|
|
|
2021-08-24 14:28:12 -05:00
|
|
|
case "cloud":
|
|
|
|
cloudCfg, cfgDiags := decodeCloudBlock(innerBlock)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cloudCfg != nil {
|
|
|
|
file.CloudConfigs = append(file.CloudConfigs, cloudCfg)
|
|
|
|
}
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
case "required_providers":
|
|
|
|
reqs, reqsDiags := decodeRequiredProvidersBlock(innerBlock)
|
|
|
|
diags = append(diags, reqsDiags...)
|
2020-04-24 09:54:24 -05:00
|
|
|
file.RequiredProviders = append(file.RequiredProviders, reqs)
|
2018-02-02 19:22:25 -06:00
|
|
|
|
2020-03-05 18:53:24 -06:00
|
|
|
case "provider_meta":
|
|
|
|
providerCfg, cfgDiags := decodeProviderMetaBlock(innerBlock)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if providerCfg != nil {
|
|
|
|
file.ProviderMetas = append(file.ProviderMetas, providerCfg)
|
|
|
|
}
|
|
|
|
|
2024-03-04 10:04:45 -06:00
|
|
|
case "encryption":
|
|
|
|
encryptionCfg, cfgDiags := config.DecodeConfig(innerBlock.Body, innerBlock.DefRange)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if encryptionCfg != nil {
|
|
|
|
file.Encryptions = append(file.Encryptions, encryptionCfg)
|
|
|
|
}
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
default:
|
|
|
|
// Should never happen because the above cases should be exhaustive
|
|
|
|
// for all block type names in our schema.
|
|
|
|
continue
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-03 17:01:57 -05:00
|
|
|
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(),
|
|
|
|
})
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
case "provider":
|
|
|
|
cfg, cfgDiags := decodeProviderBlock(block)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.ProviderConfigs = append(file.ProviderConfigs, cfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
case "variable":
|
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.
2018-03-06 19:37:51 -06:00
|
|
|
cfg, cfgDiags := decodeVariableBlock(block, override)
|
2018-02-02 19:22:25 -06:00
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Variables = append(file.Variables, cfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
case "locals":
|
|
|
|
defs, defsDiags := decodeLocalsBlock(block)
|
|
|
|
diags = append(diags, defsDiags...)
|
|
|
|
file.Locals = append(file.Locals, defs...)
|
|
|
|
|
|
|
|
case "output":
|
2018-02-06 20:05:14 -06:00
|
|
|
cfg, cfgDiags := decodeOutputBlock(block, override)
|
2018-02-02 19:22:25 -06:00
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Outputs = append(file.Outputs, cfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
case "module":
|
2018-02-06 20:05:14 -06:00
|
|
|
cfg, cfgDiags := decodeModuleBlock(block, override)
|
2018-02-02 19:22:25 -06:00
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.ModuleCalls = append(file.ModuleCalls, cfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
case "resource":
|
2020-11-20 16:56:21 -06:00
|
|
|
cfg, cfgDiags := decodeResourceBlock(block, override)
|
2018-02-02 19:22:25 -06:00
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.ManagedResources = append(file.ManagedResources, cfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
case "data":
|
2023-03-23 03:12:53 -05:00
|
|
|
cfg, cfgDiags := decodeDataBlock(block, override, false)
|
2018-02-02 19:22:25 -06:00
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.DataResources = append(file.DataResources, cfg)
|
|
|
|
}
|
|
|
|
|
2021-06-21 09:53:16 -05:00
|
|
|
case "moved":
|
2021-06-30 12:46:15 -05:00
|
|
|
cfg, cfgDiags := decodeMovedBlock(block)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Moved = append(file.Moved, cfg)
|
2021-06-21 09:53:16 -05:00
|
|
|
}
|
|
|
|
|
2023-04-26 10:28:11 -05:00
|
|
|
case "import":
|
|
|
|
cfg, cfgDiags := decodeImportBlock(block)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Import = append(file.Import, cfg)
|
|
|
|
}
|
|
|
|
|
2023-03-23 03:12:53 -05:00
|
|
|
case "check":
|
|
|
|
cfg, cfgDiags := decodeCheckBlock(block, override)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Checks = append(file.Checks, cfg)
|
|
|
|
}
|
|
|
|
|
2024-02-21 02:31:44 -06:00
|
|
|
case "removed":
|
|
|
|
cfg, cfgDiags := decodeRemovedBlock(block)
|
|
|
|
diags = append(diags, cfgDiags...)
|
|
|
|
if cfg != nil {
|
|
|
|
file.Removed = append(file.Removed, cfg)
|
|
|
|
}
|
|
|
|
|
2018-02-02 19:22:25 -06:00
|
|
|
default:
|
|
|
|
// Should never happen because the above cases should be exhaustive
|
|
|
|
// for all block type names in our schema.
|
|
|
|
continue
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return file, diags
|
|
|
|
}
|
|
|
|
|
|
|
|
// sniffCoreVersionRequirements does minimal parsing of the given body for
|
|
|
|
// "terraform" blocks with "required_version" attributes, returning the
|
|
|
|
// requirements found.
|
|
|
|
//
|
|
|
|
// This is intended to maximize the chance that we'll be able to read the
|
|
|
|
// requirements (syntax errors notwithstanding) even if the config file contains
|
2023-09-26 12:09:27 -05:00
|
|
|
// constructs that might've been added in future OpenTofu versions
|
2018-02-02 19:22:25 -06:00
|
|
|
//
|
|
|
|
// This is a "best effort" sort of method which will return constraints it is
|
|
|
|
// able to find, but may return no constraints at all if the given body is
|
|
|
|
// so invalid that it cannot be decoded at all.
|
|
|
|
func sniffCoreVersionRequirements(body hcl.Body) ([]VersionConstraint, hcl.Diagnostics) {
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
rootContent, _, diags := body.PartialContent(configFileTerraformBlockSniffRootSchema)
|
2018-02-02 19:22:25 -06:00
|
|
|
|
|
|
|
var constraints []VersionConstraint
|
|
|
|
|
|
|
|
for _, block := range rootContent.Blocks {
|
|
|
|
content, _, blockDiags := block.Body.PartialContent(configFileVersionSniffBlockSchema)
|
|
|
|
diags = append(diags, blockDiags...)
|
|
|
|
|
|
|
|
attr, exists := content.Attributes["required_version"]
|
|
|
|
if !exists {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
constraint, constraintDiags := decodeVersionConstraint(attr)
|
|
|
|
diags = append(diags, constraintDiags...)
|
|
|
|
if !constraintDiags.HasErrors() {
|
|
|
|
constraints = append(constraints, constraint)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return constraints, diags
|
|
|
|
}
|
|
|
|
|
|
|
|
// configFileSchema is the schema for the top-level of a config file. We use
|
|
|
|
// the low-level HCL API for this level so we can easily deal with each
|
|
|
|
// block type separately with its own decoding logic.
|
|
|
|
var configFileSchema = &hcl.BodySchema{
|
|
|
|
Blocks: []hcl.BlockHeaderSchema{
|
|
|
|
{
|
|
|
|
Type: "terraform",
|
|
|
|
},
|
2020-04-03 17:01:57 -05:00
|
|
|
{
|
|
|
|
// 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",
|
|
|
|
},
|
2018-02-02 19:22:25 -06:00
|
|
|
{
|
|
|
|
Type: "provider",
|
|
|
|
LabelNames: []string{"name"},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "variable",
|
|
|
|
LabelNames: []string{"name"},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "locals",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "output",
|
|
|
|
LabelNames: []string{"name"},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "module",
|
|
|
|
LabelNames: []string{"name"},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "resource",
|
|
|
|
LabelNames: []string{"type", "name"},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
Type: "data",
|
|
|
|
LabelNames: []string{"type", "name"},
|
|
|
|
},
|
2021-06-21 09:53:16 -05:00
|
|
|
{
|
|
|
|
Type: "moved",
|
|
|
|
},
|
2023-04-26 10:28:11 -05:00
|
|
|
{
|
|
|
|
Type: "import",
|
|
|
|
},
|
2023-03-23 03:12:53 -05:00
|
|
|
{
|
|
|
|
Type: "check",
|
|
|
|
LabelNames: []string{"name"},
|
|
|
|
},
|
2024-02-21 02:31:44 -06:00
|
|
|
{
|
|
|
|
Type: "removed",
|
|
|
|
},
|
2018-02-02 19:22:25 -06:00
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
// terraformBlockSchema is the schema for a top-level "terraform" block in
|
|
|
|
// a configuration file.
|
|
|
|
var terraformBlockSchema = &hcl.BodySchema{
|
|
|
|
Attributes: []hcl.AttributeSchema{
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
{Name: "required_version"},
|
|
|
|
{Name: "experiments"},
|
2021-02-26 11:48:42 -06:00
|
|
|
{Name: "language"},
|
2018-02-02 19:22:25 -06:00
|
|
|
},
|
|
|
|
Blocks: []hcl.BlockHeaderSchema{
|
|
|
|
{
|
|
|
|
Type: "backend",
|
|
|
|
LabelNames: []string{"type"},
|
|
|
|
},
|
2021-08-24 14:28:12 -05:00
|
|
|
{
|
|
|
|
Type: "cloud",
|
|
|
|
},
|
2018-02-02 19:22:25 -06:00
|
|
|
{
|
|
|
|
Type: "required_providers",
|
|
|
|
},
|
2020-03-05 18:53:24 -06:00
|
|
|
{
|
|
|
|
Type: "provider_meta",
|
|
|
|
LabelNames: []string{"provider"},
|
|
|
|
},
|
2024-03-07 07:55:57 -06:00
|
|
|
{
|
|
|
|
Type: "encryption",
|
|
|
|
},
|
2018-02-02 19:22:25 -06:00
|
|
|
},
|
|
|
|
}
|
|
|
|
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
// configFileTerraformBlockSniffRootSchema is a schema for
|
|
|
|
// sniffCoreVersionRequirements and sniffActiveExperiments.
|
|
|
|
var configFileTerraformBlockSniffRootSchema = &hcl.BodySchema{
|
2018-02-02 19:22:25 -06:00
|
|
|
Blocks: []hcl.BlockHeaderSchema{
|
|
|
|
{
|
|
|
|
Type: "terraform",
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
// configFileVersionSniffBlockSchema is a schema for sniffCoreVersionRequirements
|
|
|
|
var configFileVersionSniffBlockSchema = &hcl.BodySchema{
|
|
|
|
Attributes: []hcl.AttributeSchema{
|
|
|
|
{
|
|
|
|
Name: "required_version",
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
|
|
|
|
// configFileExperimentsSniffBlockSchema is a schema for sniffActiveExperiments,
|
|
|
|
// to decode a single attribute from inside a "terraform" block.
|
|
|
|
var configFileExperimentsSniffBlockSchema = &hcl.BodySchema{
|
|
|
|
Attributes: []hcl.AttributeSchema{
|
2021-02-26 11:48:42 -06:00
|
|
|
{Name: "experiments"},
|
|
|
|
{Name: "language"},
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
},
|
|
|
|
}
|