2018-02-08 01:40:58 +01:00
|
|
|
package configs
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
2021-02-10 17:09:35 +01:00
|
|
|
"io/ioutil"
|
2018-02-08 01:40:58 +01:00
|
|
|
"path/filepath"
|
|
|
|
"reflect"
|
|
|
|
"sort"
|
|
|
|
"strings"
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
"github.com/davecgh/go-spew/spew"
|
|
|
|
|
|
|
|
version "github.com/hashicorp/go-version"
|
2019-09-10 00:58:44 +02:00
|
|
|
"github.com/hashicorp/hcl/v2"
|
2018-02-08 01:40:58 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
func TestBuildConfig(t *testing.T) {
|
|
|
|
parser := NewParser(nil)
|
2019-06-30 09:38:36 +02:00
|
|
|
mod, diags := parser.LoadConfigDir("testdata/config-build")
|
2018-02-08 01:40:58 +01:00
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
if mod == nil {
|
|
|
|
t.Fatal("got nil root module; want non-nil")
|
|
|
|
}
|
|
|
|
|
|
|
|
versionI := 0
|
|
|
|
cfg, diags := BuildConfig(mod, ModuleWalkerFunc(
|
|
|
|
func(req *ModuleRequest) (*Module, *version.Version, hcl.Diagnostics) {
|
|
|
|
// For the sake of this test we're going to just treat our
|
|
|
|
// SourceAddr as a path relative to our fixture directory.
|
|
|
|
// A "real" implementation of ModuleWalker should accept the
|
|
|
|
// various different source address syntaxes Terraform supports.
|
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
|
|
|
sourcePath := filepath.Join("testdata/config-build", req.SourceAddr.String())
|
2018-02-08 01:40:58 +01:00
|
|
|
|
|
|
|
mod, diags := parser.LoadConfigDir(sourcePath)
|
|
|
|
version, _ := version.NewVersion(fmt.Sprintf("1.0.%d", versionI))
|
|
|
|
versionI++
|
|
|
|
return mod, version, diags
|
|
|
|
},
|
|
|
|
))
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
if cfg == nil {
|
|
|
|
t.Fatal("got nil config; want non-nil")
|
|
|
|
}
|
|
|
|
|
|
|
|
var got []string
|
|
|
|
cfg.DeepEach(func(c *Config) {
|
2018-02-10 00:32:49 +01:00
|
|
|
got = append(got, fmt.Sprintf("%s %s", strings.Join(c.Path, "."), c.Version))
|
2018-02-08 01:40:58 +01:00
|
|
|
})
|
|
|
|
sort.Strings(got)
|
|
|
|
want := []string{
|
|
|
|
" <nil>",
|
|
|
|
"child_a 1.0.0",
|
|
|
|
"child_a.child_c 1.0.1",
|
|
|
|
"child_b 1.0.2",
|
|
|
|
"child_b.child_c 1.0.3",
|
|
|
|
}
|
|
|
|
|
|
|
|
if !reflect.DeepEqual(got, want) {
|
|
|
|
t.Fatalf("wrong result\ngot: %swant: %s", spew.Sdump(got), spew.Sdump(want))
|
|
|
|
}
|
|
|
|
|
|
|
|
if _, exists := cfg.Children["child_a"].Children["child_c"].Module.Outputs["hello"]; !exists {
|
|
|
|
t.Fatalf("missing output 'hello' in child_a.child_c")
|
|
|
|
}
|
|
|
|
if _, exists := cfg.Children["child_b"].Children["child_c"].Module.Outputs["hello"]; !exists {
|
|
|
|
t.Fatalf("missing output 'hello' in child_b.child_c")
|
|
|
|
}
|
|
|
|
if cfg.Children["child_a"].Children["child_c"].Module == cfg.Children["child_b"].Children["child_c"].Module {
|
|
|
|
t.Fatalf("child_a.child_c is same object as child_b.child_c; should not be")
|
|
|
|
}
|
|
|
|
}
|
2019-07-17 00:58:40 +02:00
|
|
|
|
|
|
|
func TestBuildConfigDiags(t *testing.T) {
|
|
|
|
parser := NewParser(nil)
|
|
|
|
mod, diags := parser.LoadConfigDir("testdata/nested-errors")
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
if mod == nil {
|
|
|
|
t.Fatal("got nil root module; want non-nil")
|
|
|
|
}
|
|
|
|
|
|
|
|
versionI := 0
|
|
|
|
cfg, diags := BuildConfig(mod, ModuleWalkerFunc(
|
|
|
|
func(req *ModuleRequest) (*Module, *version.Version, hcl.Diagnostics) {
|
|
|
|
// For the sake of this test we're going to just treat our
|
|
|
|
// SourceAddr as a path relative to our fixture directory.
|
|
|
|
// A "real" implementation of ModuleWalker should accept the
|
|
|
|
// various different source address syntaxes Terraform supports.
|
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
|
|
|
sourcePath := filepath.Join("testdata/nested-errors", req.SourceAddr.String())
|
2019-07-17 00:58:40 +02:00
|
|
|
|
|
|
|
mod, diags := parser.LoadConfigDir(sourcePath)
|
|
|
|
version, _ := version.NewVersion(fmt.Sprintf("1.0.%d", versionI))
|
|
|
|
versionI++
|
|
|
|
return mod, version, diags
|
|
|
|
},
|
|
|
|
))
|
|
|
|
|
|
|
|
wantDiag := `testdata/nested-errors/child_c/child_c.tf:5,1-8: ` +
|
|
|
|
`Unsupported block type; Blocks of type "invalid" are not expected here.`
|
|
|
|
assertExactDiagnostics(t, diags, []string{wantDiag})
|
|
|
|
|
|
|
|
// we should still have module structure loaded
|
|
|
|
var got []string
|
|
|
|
cfg.DeepEach(func(c *Config) {
|
|
|
|
got = append(got, fmt.Sprintf("%s %s", strings.Join(c.Path, "."), c.Version))
|
|
|
|
})
|
|
|
|
sort.Strings(got)
|
|
|
|
want := []string{
|
|
|
|
" <nil>",
|
|
|
|
"child_a 1.0.0",
|
|
|
|
"child_a.child_c 1.0.1",
|
|
|
|
}
|
|
|
|
|
|
|
|
if !reflect.DeepEqual(got, want) {
|
|
|
|
t.Fatalf("wrong result\ngot: %swant: %s", spew.Sdump(got), spew.Sdump(want))
|
|
|
|
}
|
|
|
|
}
|
2020-11-18 01:42:36 +01:00
|
|
|
|
|
|
|
func TestBuildConfigChildModuleBackend(t *testing.T) {
|
|
|
|
parser := NewParser(nil)
|
|
|
|
mod, diags := parser.LoadConfigDir("testdata/nested-backend-warning")
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
if mod == nil {
|
|
|
|
t.Fatal("got nil root module; want non-nil")
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg, diags := BuildConfig(mod, ModuleWalkerFunc(
|
|
|
|
func(req *ModuleRequest) (*Module, *version.Version, hcl.Diagnostics) {
|
|
|
|
// For the sake of this test we're going to just treat our
|
|
|
|
// SourceAddr as a path relative to our fixture directory.
|
|
|
|
// A "real" implementation of ModuleWalker should accept the
|
|
|
|
// various different source address syntaxes Terraform supports.
|
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
|
|
|
sourcePath := filepath.Join("testdata/nested-backend-warning", req.SourceAddr.String())
|
2020-11-18 01:42:36 +01:00
|
|
|
|
|
|
|
mod, diags := parser.LoadConfigDir(sourcePath)
|
|
|
|
version, _ := version.NewVersion("1.0.0")
|
|
|
|
return mod, version, diags
|
|
|
|
},
|
|
|
|
))
|
|
|
|
|
|
|
|
assertDiagnosticSummary(t, diags, "Backend configuration ignored")
|
|
|
|
|
|
|
|
// we should still have module structure loaded
|
|
|
|
var got []string
|
|
|
|
cfg.DeepEach(func(c *Config) {
|
|
|
|
got = append(got, fmt.Sprintf("%s %s", strings.Join(c.Path, "."), c.Version))
|
|
|
|
})
|
|
|
|
sort.Strings(got)
|
|
|
|
want := []string{
|
|
|
|
" <nil>",
|
|
|
|
"child 1.0.0",
|
|
|
|
}
|
|
|
|
|
|
|
|
if !reflect.DeepEqual(got, want) {
|
|
|
|
t.Fatalf("wrong result\ngot: %swant: %s", spew.Sdump(got), spew.Sdump(want))
|
|
|
|
}
|
|
|
|
}
|
2021-02-10 17:09:35 +01:00
|
|
|
|
|
|
|
func TestBuildConfigInvalidModules(t *testing.T) {
|
|
|
|
testDir := "testdata/config-diagnostics"
|
|
|
|
dirs, err := ioutil.ReadDir(testDir)
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, info := range dirs {
|
|
|
|
name := info.Name()
|
|
|
|
t.Run(name, func(t *testing.T) {
|
|
|
|
parser := NewParser(nil)
|
|
|
|
path := filepath.Join(testDir, name)
|
|
|
|
|
|
|
|
mod, diags := parser.LoadConfigDir(path)
|
|
|
|
if diags.HasErrors() {
|
|
|
|
// these tests should only trigger errors that are caught in
|
|
|
|
// the config loader.
|
|
|
|
t.Errorf("error loading config dir")
|
|
|
|
for _, diag := range diags {
|
|
|
|
t.Logf("- %s", diag)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
readDiags := func(data []byte, _ error) []string {
|
|
|
|
var expected []string
|
|
|
|
for _, s := range strings.Split(string(data), "\n") {
|
|
|
|
msg := strings.TrimSpace(s)
|
|
|
|
msg = strings.ReplaceAll(msg, `\n`, "\n")
|
|
|
|
if msg != "" {
|
|
|
|
expected = append(expected, msg)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return expected
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load expected errors and warnings.
|
|
|
|
// Each line in the file is matched as a substring against the
|
|
|
|
// diagnostic outputs.
|
|
|
|
// Capturing part of the path and source range in the message lets
|
|
|
|
// us also ensure the diagnostic is being attributed to the
|
|
|
|
// expected location in the source, but is not required.
|
|
|
|
// The literal characters `\n` are replaced with newlines, but
|
|
|
|
// otherwise the string is unchanged.
|
|
|
|
expectedErrs := readDiags(ioutil.ReadFile(filepath.Join(testDir, name, "errors")))
|
|
|
|
expectedWarnings := readDiags(ioutil.ReadFile(filepath.Join(testDir, name, "warnings")))
|
|
|
|
|
|
|
|
_, buildDiags := BuildConfig(mod, ModuleWalkerFunc(
|
|
|
|
func(req *ModuleRequest) (*Module, *version.Version, hcl.Diagnostics) {
|
|
|
|
// for simplicity, these tests will treat all source
|
|
|
|
// addresses as relative to the root module
|
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
|
|
|
sourcePath := filepath.Join(path, req.SourceAddr.String())
|
2021-02-10 17:09:35 +01:00
|
|
|
mod, diags := parser.LoadConfigDir(sourcePath)
|
|
|
|
version, _ := version.NewVersion("1.0.0")
|
|
|
|
return mod, version, diags
|
|
|
|
},
|
|
|
|
))
|
|
|
|
|
|
|
|
// we can make this less repetitive later if we want
|
|
|
|
for _, msg := range expectedErrs {
|
|
|
|
found := false
|
|
|
|
for _, diag := range buildDiags {
|
|
|
|
if diag.Severity == hcl.DiagError && strings.Contains(diag.Error(), msg) {
|
|
|
|
found = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !found {
|
configs: Refined error messages for mismatched provider passing
This set of diagnostic messages is under a number of unusual constraints
that make them tough to get right:
- They are discussing a couple finicky concepts which authors are
likely to be encountering for the first time in these error messages:
the idea of "local names" for providers, the relationship between those
and provider source addresses, and additional ("aliased") provider
configurations.
- They are reporting concerns that span across a module call boundary,
and so need to take care to be clear about whether they are talking
about a problem in the caller or a problem in the callee.
- Some of them are effectively deprecation warnings for features that
might be in use by a third-party module that the user doesn't control,
in which case they have no recourse to address them aside from opening
a feature request with the upstream module maintainer.
- Terraform has, for backward-compatibility reasons, a lot of implied
default behaviors regarding providers and provider configurations,
and these errors can arise in situations where Terraform's assumptions
don't match the author's intent, and so we need to be careful to
explain what Terraform assumed in order to make the messages
understandable.
After seeing some confusion with these messages in the community, and
being somewhat confused by some of them myself, I decided to try to edit
them a bit for consistency of terminology (both between the messages and
with terminology in our docs), being explicit about caller vs. callee
by naming them in the messages, and making explicit what would otherwise
be implicit with regard to the correspondences between provider source
addresses and local names.
My assumed audience for all of these messages is the author of the caller
module, because it's the caller who is responsible for creating the
relationship between caller and callee. As much as possible I tried to
make the messages include specific actions for that author to take to
quiet the warning or fix the error, but some of the warnings are only
fixable by the callee's maintainer and so those messages are, in effect,
a suggestion to send a request to the author to stop using a deprecated
feature.
I think these new messages are also not ideal by any means, because it's
just tough to pack so much information into concise messages while being
clear and consistent, but I hope at least this will give users seeing
these messages enough context to infer what's going on, possibly with the
help of our documentation.
I intentionally didn't change which cases Terraform will return warnings
or errors -- only the message texts -- although I did highlight in a
comment in one of the tests that what it is a asserting seems a bit
suspicious to me. I don't intend to address that here; instead, I intend
that note to be something to refer to if we later see a bug report that
calls that behavior into question.
This does actually silence some _unrelated_ warnings and errors in cases
where a provider block has an invalid provider local name as its label,
because our other functions for dealing with provider addresses are
written to panic if given invalid addresses under the assumption that
earlier code will have guarded against that. Doing this allowed for the
provider configuration validation logic to safely include more information
about the configuration as helpful context, without risking tripping over
known-invalid configuration and panicking in the process.
2022-03-09 21:26:37 +01:00
|
|
|
t.Errorf("Expected error diagnostic containing:\n %s", msg)
|
2021-02-10 17:09:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, diag := range buildDiags {
|
|
|
|
if diag.Severity != hcl.DiagError {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
found := false
|
|
|
|
for _, msg := range expectedErrs {
|
|
|
|
if strings.Contains(diag.Error(), msg) {
|
|
|
|
found = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !found {
|
configs: Refined error messages for mismatched provider passing
This set of diagnostic messages is under a number of unusual constraints
that make them tough to get right:
- They are discussing a couple finicky concepts which authors are
likely to be encountering for the first time in these error messages:
the idea of "local names" for providers, the relationship between those
and provider source addresses, and additional ("aliased") provider
configurations.
- They are reporting concerns that span across a module call boundary,
and so need to take care to be clear about whether they are talking
about a problem in the caller or a problem in the callee.
- Some of them are effectively deprecation warnings for features that
might be in use by a third-party module that the user doesn't control,
in which case they have no recourse to address them aside from opening
a feature request with the upstream module maintainer.
- Terraform has, for backward-compatibility reasons, a lot of implied
default behaviors regarding providers and provider configurations,
and these errors can arise in situations where Terraform's assumptions
don't match the author's intent, and so we need to be careful to
explain what Terraform assumed in order to make the messages
understandable.
After seeing some confusion with these messages in the community, and
being somewhat confused by some of them myself, I decided to try to edit
them a bit for consistency of terminology (both between the messages and
with terminology in our docs), being explicit about caller vs. callee
by naming them in the messages, and making explicit what would otherwise
be implicit with regard to the correspondences between provider source
addresses and local names.
My assumed audience for all of these messages is the author of the caller
module, because it's the caller who is responsible for creating the
relationship between caller and callee. As much as possible I tried to
make the messages include specific actions for that author to take to
quiet the warning or fix the error, but some of the warnings are only
fixable by the callee's maintainer and so those messages are, in effect,
a suggestion to send a request to the author to stop using a deprecated
feature.
I think these new messages are also not ideal by any means, because it's
just tough to pack so much information into concise messages while being
clear and consistent, but I hope at least this will give users seeing
these messages enough context to infer what's going on, possibly with the
help of our documentation.
I intentionally didn't change which cases Terraform will return warnings
or errors -- only the message texts -- although I did highlight in a
comment in one of the tests that what it is a asserting seems a bit
suspicious to me. I don't intend to address that here; instead, I intend
that note to be something to refer to if we later see a bug report that
calls that behavior into question.
This does actually silence some _unrelated_ warnings and errors in cases
where a provider block has an invalid provider local name as its label,
because our other functions for dealing with provider addresses are
written to panic if given invalid addresses under the assumption that
earlier code will have guarded against that. Doing this allowed for the
provider configuration validation logic to safely include more information
about the configuration as helpful context, without risking tripping over
known-invalid configuration and panicking in the process.
2022-03-09 21:26:37 +01:00
|
|
|
t.Errorf("Unexpected error:\n %s", diag)
|
2021-02-10 17:09:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, msg := range expectedWarnings {
|
|
|
|
found := false
|
|
|
|
for _, diag := range buildDiags {
|
|
|
|
if diag.Severity == hcl.DiagWarning && strings.Contains(diag.Error(), msg) {
|
|
|
|
found = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !found {
|
configs: Refined error messages for mismatched provider passing
This set of diagnostic messages is under a number of unusual constraints
that make them tough to get right:
- They are discussing a couple finicky concepts which authors are
likely to be encountering for the first time in these error messages:
the idea of "local names" for providers, the relationship between those
and provider source addresses, and additional ("aliased") provider
configurations.
- They are reporting concerns that span across a module call boundary,
and so need to take care to be clear about whether they are talking
about a problem in the caller or a problem in the callee.
- Some of them are effectively deprecation warnings for features that
might be in use by a third-party module that the user doesn't control,
in which case they have no recourse to address them aside from opening
a feature request with the upstream module maintainer.
- Terraform has, for backward-compatibility reasons, a lot of implied
default behaviors regarding providers and provider configurations,
and these errors can arise in situations where Terraform's assumptions
don't match the author's intent, and so we need to be careful to
explain what Terraform assumed in order to make the messages
understandable.
After seeing some confusion with these messages in the community, and
being somewhat confused by some of them myself, I decided to try to edit
them a bit for consistency of terminology (both between the messages and
with terminology in our docs), being explicit about caller vs. callee
by naming them in the messages, and making explicit what would otherwise
be implicit with regard to the correspondences between provider source
addresses and local names.
My assumed audience for all of these messages is the author of the caller
module, because it's the caller who is responsible for creating the
relationship between caller and callee. As much as possible I tried to
make the messages include specific actions for that author to take to
quiet the warning or fix the error, but some of the warnings are only
fixable by the callee's maintainer and so those messages are, in effect,
a suggestion to send a request to the author to stop using a deprecated
feature.
I think these new messages are also not ideal by any means, because it's
just tough to pack so much information into concise messages while being
clear and consistent, but I hope at least this will give users seeing
these messages enough context to infer what's going on, possibly with the
help of our documentation.
I intentionally didn't change which cases Terraform will return warnings
or errors -- only the message texts -- although I did highlight in a
comment in one of the tests that what it is a asserting seems a bit
suspicious to me. I don't intend to address that here; instead, I intend
that note to be something to refer to if we later see a bug report that
calls that behavior into question.
This does actually silence some _unrelated_ warnings and errors in cases
where a provider block has an invalid provider local name as its label,
because our other functions for dealing with provider addresses are
written to panic if given invalid addresses under the assumption that
earlier code will have guarded against that. Doing this allowed for the
provider configuration validation logic to safely include more information
about the configuration as helpful context, without risking tripping over
known-invalid configuration and panicking in the process.
2022-03-09 21:26:37 +01:00
|
|
|
t.Errorf("Expected warning diagnostic containing:\n %s", msg)
|
2021-02-10 17:09:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, diag := range buildDiags {
|
|
|
|
if diag.Severity != hcl.DiagWarning {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
found := false
|
|
|
|
for _, msg := range expectedWarnings {
|
|
|
|
if strings.Contains(diag.Error(), msg) {
|
|
|
|
found = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !found {
|
configs: Refined error messages for mismatched provider passing
This set of diagnostic messages is under a number of unusual constraints
that make them tough to get right:
- They are discussing a couple finicky concepts which authors are
likely to be encountering for the first time in these error messages:
the idea of "local names" for providers, the relationship between those
and provider source addresses, and additional ("aliased") provider
configurations.
- They are reporting concerns that span across a module call boundary,
and so need to take care to be clear about whether they are talking
about a problem in the caller or a problem in the callee.
- Some of them are effectively deprecation warnings for features that
might be in use by a third-party module that the user doesn't control,
in which case they have no recourse to address them aside from opening
a feature request with the upstream module maintainer.
- Terraform has, for backward-compatibility reasons, a lot of implied
default behaviors regarding providers and provider configurations,
and these errors can arise in situations where Terraform's assumptions
don't match the author's intent, and so we need to be careful to
explain what Terraform assumed in order to make the messages
understandable.
After seeing some confusion with these messages in the community, and
being somewhat confused by some of them myself, I decided to try to edit
them a bit for consistency of terminology (both between the messages and
with terminology in our docs), being explicit about caller vs. callee
by naming them in the messages, and making explicit what would otherwise
be implicit with regard to the correspondences between provider source
addresses and local names.
My assumed audience for all of these messages is the author of the caller
module, because it's the caller who is responsible for creating the
relationship between caller and callee. As much as possible I tried to
make the messages include specific actions for that author to take to
quiet the warning or fix the error, but some of the warnings are only
fixable by the callee's maintainer and so those messages are, in effect,
a suggestion to send a request to the author to stop using a deprecated
feature.
I think these new messages are also not ideal by any means, because it's
just tough to pack so much information into concise messages while being
clear and consistent, but I hope at least this will give users seeing
these messages enough context to infer what's going on, possibly with the
help of our documentation.
I intentionally didn't change which cases Terraform will return warnings
or errors -- only the message texts -- although I did highlight in a
comment in one of the tests that what it is a asserting seems a bit
suspicious to me. I don't intend to address that here; instead, I intend
that note to be something to refer to if we later see a bug report that
calls that behavior into question.
This does actually silence some _unrelated_ warnings and errors in cases
where a provider block has an invalid provider local name as its label,
because our other functions for dealing with provider addresses are
written to panic if given invalid addresses under the assumption that
earlier code will have guarded against that. Doing this allowed for the
provider configuration validation logic to safely include more information
about the configuration as helpful context, without risking tripping over
known-invalid configuration and panicking in the process.
2022-03-09 21:26:37 +01:00
|
|
|
t.Errorf("Unexpected warning:\n %s", diag)
|
2021-02-10 17:09:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|