2018-02-07 01:28:40 +01:00
|
|
|
package configs
|
|
|
|
|
|
|
|
import (
|
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-07 02:37:51 +01:00
|
|
|
"fmt"
|
|
|
|
|
2021-05-17 21:00:50 +02:00
|
|
|
"github.com/hashicorp/terraform/internal/addrs"
|
2018-04-06 20:07:39 +02:00
|
|
|
|
2019-09-10 00:58:44 +02:00
|
|
|
"github.com/hashicorp/hcl/v2"
|
2018-02-07 01:28:40 +01:00
|
|
|
"github.com/zclconf/go-cty/cty"
|
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-07 02:37:51 +01:00
|
|
|
"github.com/zclconf/go-cty/cty/convert"
|
2018-02-07 01:28:40 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// The methods in this file are used by Module.mergeFile to apply overrides
|
|
|
|
// to our different configuration elements. These methods all follow the
|
|
|
|
// pattern of mutating the receiver to incorporate settings from the parameter,
|
|
|
|
// returning error diagnostics if any aspect of the parameter cannot be merged
|
|
|
|
// into the receiver for some reason.
|
|
|
|
//
|
|
|
|
// User expectation is that anything _explicitly_ set in the given object
|
|
|
|
// should take precedence over the corresponding settings in the receiver,
|
|
|
|
// but that anything omitted in the given object should be left unchanged.
|
|
|
|
// In some cases it may be reasonable to do a "deep merge" of certain nested
|
|
|
|
// features, if it is possible to unambiguously correlate the nested elements
|
|
|
|
// and their behaviors are orthogonal to each other.
|
|
|
|
|
|
|
|
func (p *Provider) merge(op *Provider) hcl.Diagnostics {
|
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
|
|
|
if op.Version.Required != nil {
|
|
|
|
p.Version = op.Version
|
|
|
|
}
|
|
|
|
|
2018-03-16 23:16:26 +01:00
|
|
|
p.Config = MergeBodies(p.Config, op.Config)
|
2018-02-07 01:28:40 +01:00
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|
|
|
|
|
|
|
|
func (v *Variable) merge(ov *Variable) hcl.Diagnostics {
|
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
2018-02-07 03:05:14 +01:00
|
|
|
if ov.DescriptionSet {
|
2018-02-07 01:28:40 +01:00
|
|
|
v.Description = ov.Description
|
2018-02-07 03:05:14 +01:00
|
|
|
v.DescriptionSet = ov.DescriptionSet
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
2020-09-30 23:23:54 +02:00
|
|
|
if ov.SensitiveSet {
|
|
|
|
v.Sensitive = ov.Sensitive
|
|
|
|
v.SensitiveSet = ov.SensitiveSet
|
|
|
|
}
|
2018-02-07 01:28:40 +01:00
|
|
|
if ov.Default != cty.NilVal {
|
|
|
|
v.Default = ov.Default
|
|
|
|
}
|
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-07 02:37:51 +01:00
|
|
|
if ov.Type != cty.NilType {
|
|
|
|
v.Type = ov.Type
|
2021-09-10 16:58:44 +02:00
|
|
|
v.ConstraintType = ov.ConstraintType
|
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-07 02:37:51 +01:00
|
|
|
}
|
|
|
|
if ov.ParsingMode != 0 {
|
|
|
|
v.ParsingMode = ov.ParsingMode
|
|
|
|
}
|
2021-10-29 23:01:26 +02:00
|
|
|
if ov.NullableSet {
|
|
|
|
v.Nullable = ov.Nullable
|
|
|
|
v.NullableSet = ov.NullableSet
|
|
|
|
}
|
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-07 02:37:51 +01:00
|
|
|
|
|
|
|
// If the override file overrode type without default or vice-versa then
|
|
|
|
// it may have created an invalid situation, which we'll catch now by
|
|
|
|
// attempting to re-convert the value.
|
|
|
|
//
|
|
|
|
// Note that here we may be re-converting an already-converted base value
|
|
|
|
// from the base config. This will be a no-op if the type was not changed,
|
|
|
|
// but in particular might be user-observable in the edge case where the
|
|
|
|
// literal value in config could've been converted to the overridden type
|
|
|
|
// constraint but the converted value cannot. In practice, this situation
|
|
|
|
// should be rare since most of our conversions are interchangable.
|
|
|
|
if v.Default != cty.NilVal {
|
2021-09-10 16:58:44 +02:00
|
|
|
val, err := convert.Convert(v.Default, v.ConstraintType)
|
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-07 02:37:51 +01:00
|
|
|
if err != nil {
|
|
|
|
// What exactly we'll say in the error message here depends on whether
|
|
|
|
// it was Default or Type that was overridden here.
|
|
|
|
switch {
|
|
|
|
case ov.Type != cty.NilType && ov.Default == cty.NilVal:
|
|
|
|
// If only the type was overridden
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Invalid default value for variable",
|
|
|
|
Detail: fmt.Sprintf("Overriding this variable's type constraint has made its default value invalid: %s.", err),
|
|
|
|
Subject: &ov.DeclRange,
|
|
|
|
})
|
|
|
|
case ov.Type == cty.NilType && ov.Default != cty.NilVal:
|
|
|
|
// Only the default was overridden
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Invalid default value for variable",
|
|
|
|
Detail: fmt.Sprintf("The overridden default value for this variable is not compatible with the variable's type constraint: %s.", err),
|
|
|
|
Subject: &ov.DeclRange,
|
|
|
|
})
|
|
|
|
default:
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Invalid default value for variable",
|
|
|
|
Detail: fmt.Sprintf("This variable's default value is not compatible with its type constraint: %s.", err),
|
|
|
|
Subject: &ov.DeclRange,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
v.Default = val
|
|
|
|
}
|
2021-10-29 23:01:26 +02:00
|
|
|
|
|
|
|
// ensure a null default wasn't merged in when it is not allowed
|
|
|
|
if !v.Nullable && v.Default.IsNull() {
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Invalid default value for variable",
|
|
|
|
Detail: "A null default value is not valid when nullable=false.",
|
|
|
|
Subject: &ov.DeclRange,
|
|
|
|
})
|
|
|
|
}
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|
|
|
|
|
|
|
|
func (l *Local) merge(ol *Local) hcl.Diagnostics {
|
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
|
|
|
// Since a local is just a single expression in configuration, the
|
|
|
|
// override definition entirely replaces the base definition, including
|
|
|
|
// the source range so that we'll send the user to the right place if
|
|
|
|
// there is an error.
|
|
|
|
l.Expr = ol.Expr
|
|
|
|
l.DeclRange = ol.DeclRange
|
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|
|
|
|
|
|
|
|
func (o *Output) merge(oo *Output) hcl.Diagnostics {
|
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
|
|
|
if oo.Description != "" {
|
|
|
|
o.Description = oo.Description
|
|
|
|
}
|
|
|
|
if oo.Expr != nil {
|
|
|
|
o.Expr = oo.Expr
|
|
|
|
}
|
2018-02-07 03:05:14 +01:00
|
|
|
if oo.SensitiveSet {
|
2018-02-07 01:28:40 +01:00
|
|
|
o.Sensitive = oo.Sensitive
|
2018-02-07 03:05:14 +01:00
|
|
|
o.SensitiveSet = oo.SensitiveSet
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// We don't allow depends_on to be overridden because that is likely to
|
|
|
|
// cause confusing misbehavior.
|
|
|
|
if len(oo.DependsOn) != 0 {
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Unsupported override",
|
|
|
|
Detail: "The depends_on argument may not be overridden.",
|
|
|
|
Subject: oo.DependsOn[0].SourceRange().Ptr(), // the first item is the closest range we have
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|
|
|
|
|
|
|
|
func (mc *ModuleCall) merge(omc *ModuleCall) hcl.Diagnostics {
|
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
2018-02-07 03:05:14 +01:00
|
|
|
if omc.SourceSet {
|
2018-02-07 01:28:40 +01:00
|
|
|
mc.SourceAddr = omc.SourceAddr
|
Refactoring of module source addresses and module installation
It's been a long while since we gave close attention to the codepaths for
module source address parsing and external module package installation.
Due to their age, these codepaths often diverged from our modern practices
such as representing address types in the addrs package, and encapsulating
package installation details only in a particular location.
In particular, this refactor makes source address parsing a separate step
from module installation, which therefore makes the result of that parsing
available to other Terraform subsystems which work with the configuration
representation objects.
This also presented the opportunity to better encapsulate our use of
go-getter into a new package "getmodules" (echoing "getproviders"), which
is intended to be the only part of Terraform that directly interacts with
go-getter.
This is largely just a refactor of the existing functionality into a new
code organization, but there is one notable change in behavior here: the
source address parsing now happens during configuration loading rather
than module installation, which may cause errors about invalid addresses
to be returned in different situations than before. That counts as
backward compatible because we only promise to remain compatible with
configurations that are _valid_, which means that they can be initialized,
planned, and applied without any errors. This doesn't introduce any new
error cases, and instead just makes a pre-existing error case be detected
earlier.
Our module registry client is still using its own special module address
type from registry/regsrc for now, with a small shim from the new
addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also
rework the registry client to work with the new address type, but this
commit is already big enough as it is.
2021-05-28 04:24:59 +02:00
|
|
|
mc.SourceAddrRaw = omc.SourceAddrRaw
|
2018-02-07 01:28:40 +01:00
|
|
|
mc.SourceAddrRange = omc.SourceAddrRange
|
2018-02-07 03:05:14 +01:00
|
|
|
mc.SourceSet = omc.SourceSet
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if omc.Count != nil {
|
|
|
|
mc.Count = omc.Count
|
|
|
|
}
|
|
|
|
|
|
|
|
if omc.ForEach != nil {
|
|
|
|
mc.ForEach = omc.ForEach
|
|
|
|
}
|
|
|
|
|
|
|
|
if len(omc.Version.Required) != 0 {
|
|
|
|
mc.Version = omc.Version
|
|
|
|
}
|
|
|
|
|
2018-03-16 23:16:26 +01:00
|
|
|
mc.Config = MergeBodies(mc.Config, omc.Config)
|
2018-02-07 01:28:40 +01:00
|
|
|
|
2020-08-11 17:46:40 +02:00
|
|
|
if len(omc.Providers) != 0 {
|
|
|
|
mc.Providers = omc.Providers
|
|
|
|
}
|
|
|
|
|
2018-02-07 01:28:40 +01:00
|
|
|
// We don't allow depends_on to be overridden because that is likely to
|
|
|
|
// cause confusing misbehavior.
|
|
|
|
if len(mc.DependsOn) != 0 {
|
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Unsupported override",
|
|
|
|
Detail: "The depends_on argument may not be overridden.",
|
|
|
|
Subject: mc.DependsOn[0].SourceRange().Ptr(), // the first item is the closest range we have
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|
|
|
|
|
2020-04-24 16:54:24 +02:00
|
|
|
func (r *Resource) merge(or *Resource, rps map[string]*RequiredProvider) hcl.Diagnostics {
|
2018-02-07 01:28:40 +01:00
|
|
|
var diags hcl.Diagnostics
|
|
|
|
|
2018-04-06 20:07:39 +02:00
|
|
|
if r.Mode != or.Mode {
|
|
|
|
// This is always a programming error, since managed and data resources
|
|
|
|
// are kept in separate maps in the configuration structures.
|
|
|
|
panic(fmt.Errorf("can't merge %s into %s", or.Mode, r.Mode))
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
2018-04-06 20:07:39 +02:00
|
|
|
|
2018-02-07 01:28:40 +01:00
|
|
|
if or.Count != nil {
|
|
|
|
r.Count = or.Count
|
|
|
|
}
|
|
|
|
if or.ForEach != nil {
|
|
|
|
r.ForEach = or.ForEach
|
|
|
|
}
|
2020-03-16 19:36:16 +01:00
|
|
|
|
2018-02-07 01:28:40 +01:00
|
|
|
if or.ProviderConfigRef != nil {
|
|
|
|
r.ProviderConfigRef = or.ProviderConfigRef
|
2020-04-24 16:54:24 +02:00
|
|
|
if existing, exists := rps[or.ProviderConfigRef.Name]; exists {
|
2020-03-16 19:36:16 +01:00
|
|
|
r.Provider = existing.Type
|
|
|
|
} else {
|
2020-04-02 01:11:15 +02:00
|
|
|
r.Provider = addrs.ImpliedProviderForUnqualifiedType(r.ProviderConfigRef.Name)
|
2020-03-16 19:36:16 +01:00
|
|
|
}
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
2020-03-16 19:36:16 +01:00
|
|
|
|
|
|
|
// Provider FQN is set by Terraform during Merge
|
|
|
|
|
2018-04-06 20:07:39 +02:00
|
|
|
if r.Mode == addrs.ManagedResourceMode {
|
|
|
|
// or.Managed is always non-nil for managed resource mode
|
2018-02-07 01:28:40 +01:00
|
|
|
|
2018-04-06 20:07:39 +02:00
|
|
|
if or.Managed.Connection != nil {
|
|
|
|
r.Managed.Connection = or.Managed.Connection
|
|
|
|
}
|
|
|
|
if or.Managed.CreateBeforeDestroySet {
|
|
|
|
r.Managed.CreateBeforeDestroy = or.Managed.CreateBeforeDestroy
|
|
|
|
r.Managed.CreateBeforeDestroySet = or.Managed.CreateBeforeDestroySet
|
|
|
|
}
|
|
|
|
if len(or.Managed.IgnoreChanges) != 0 {
|
|
|
|
r.Managed.IgnoreChanges = or.Managed.IgnoreChanges
|
|
|
|
}
|
2021-11-01 20:08:30 +01:00
|
|
|
if or.Managed.IgnoreAllChanges {
|
|
|
|
r.Managed.IgnoreAllChanges = true
|
|
|
|
}
|
2018-04-06 20:07:39 +02:00
|
|
|
if or.Managed.PreventDestroySet {
|
|
|
|
r.Managed.PreventDestroy = or.Managed.PreventDestroy
|
|
|
|
r.Managed.PreventDestroySet = or.Managed.PreventDestroySet
|
|
|
|
}
|
|
|
|
if len(or.Managed.Provisioners) != 0 {
|
|
|
|
r.Managed.Provisioners = or.Managed.Provisioners
|
|
|
|
}
|
2018-02-07 01:28:40 +01:00
|
|
|
}
|
|
|
|
|
2018-03-16 23:16:26 +01:00
|
|
|
r.Config = MergeBodies(r.Config, or.Config)
|
2018-02-07 01:28:40 +01:00
|
|
|
|
|
|
|
// We don't allow depends_on to be overridden because that is likely to
|
|
|
|
// cause confusing misbehavior.
|
2018-04-06 20:07:39 +02:00
|
|
|
if len(or.DependsOn) != 0 {
|
2018-02-07 01:28:40 +01:00
|
|
|
diags = append(diags, &hcl.Diagnostic{
|
|
|
|
Severity: hcl.DiagError,
|
|
|
|
Summary: "Unsupported override",
|
|
|
|
Detail: "The depends_on argument may not be overridden.",
|
2018-04-06 20:07:39 +02:00
|
|
|
Subject: or.DependsOn[0].SourceRange().Ptr(), // the first item is the closest range we have
|
2018-02-07 01:28:40 +01:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
return diags
|
|
|
|
}
|