terraform/configs/module_merge.go

255 lines
7.7 KiB
Go
Raw Normal View History

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"
"github.com/hashicorp/terraform/addrs"
"github.com/hashicorp/hcl/v2"
"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"
)
// 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
}
p.Config = MergeBodies(p.Config, op.Config)
return diags
}
func mergeProviderVersionConstraints(recv map[string]ProviderRequirements, ovrd []*RequiredProvider) {
// Any provider name that's mentioned in the override gets nilled out in
// our map so that we'll rebuild it below. Any provider not mentioned is
// left unchanged.
for _, reqd := range ovrd {
delete(recv, reqd.Name)
}
for _, reqd := range ovrd {
var fqn addrs.Provider
if reqd.Source.SourceStr != "" {
// any errors parsing the source string will have already been captured.
fqn, _ = addrs.ParseProviderSourceString(reqd.Source.SourceStr)
} else {
fqn = addrs.NewLegacyProvider(reqd.Name)
}
recv[reqd.Name] = ProviderRequirements{Type: fqn, VersionConstraints: []VersionConstraint{reqd.Requirement}}
}
}
func (v *Variable) merge(ov *Variable) hcl.Diagnostics {
var diags hcl.Diagnostics
if ov.DescriptionSet {
v.Description = ov.Description
v.DescriptionSet = ov.DescriptionSet
}
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
}
if ov.ParsingMode != 0 {
v.ParsingMode = ov.ParsingMode
}
// 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 {
val, err := convert.Convert(v.Default, v.Type)
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
}
}
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
}
if oo.SensitiveSet {
o.Sensitive = oo.Sensitive
o.SensitiveSet = oo.SensitiveSet
}
// 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
if omc.SourceSet {
mc.SourceAddr = omc.SourceAddr
mc.SourceAddrRange = omc.SourceAddrRange
mc.SourceSet = omc.SourceSet
}
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
}
mc.Config = MergeBodies(mc.Config, omc.Config)
// 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
}
func (r *Resource) merge(or *Resource) hcl.Diagnostics {
var diags hcl.Diagnostics
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))
}
if or.Count != nil {
r.Count = or.Count
}
if or.ForEach != nil {
r.ForEach = or.ForEach
}
if or.ProviderConfigRef != nil {
r.ProviderConfigRef = or.ProviderConfigRef
}
if r.Mode == addrs.ManagedResourceMode {
// or.Managed is always non-nil for managed resource mode
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
}
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
}
}
r.Config = MergeBodies(r.Config, or.Config)
// We don't allow depends_on to be overridden because that is likely to
// cause confusing misbehavior.
if len(or.DependsOn) != 0 {
diags = append(diags, &hcl.Diagnostic{
Severity: hcl.DiagError,
Summary: "Unsupported override",
Detail: "The depends_on argument may not be overridden.",
Subject: or.DependsOn[0].SourceRange().Ptr(), // the first item is the closest range we have
})
}
return diags
}