IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2024-12-28 01:41:48 -06:00
Code Issues Packages Projects Releases Wiki Activity
e6049d79b7
opentofu/terraform/eval_validate_test.go

352 lines
8.1 KiB
Go
Raw Normal View History

core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
package terraform
import (
"errors"
"strings"
"testing"
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
"github.com/hashicorp/hcl2/hcl"
"github.com/hashicorp/terraform/config/configschema"
"github.com/hashicorp/terraform/tfdiags"
"github.com/hashicorp/terraform/configs"
"github.com/zclconf/go-cty/cty"
"github.com/hashicorp/terraform/addrs"
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
)
func TestEvalValidateResource_managedResource(t *testing.T) {
mp := testProvider("aws")
mp.ValidateResourceFn = func(rt string, c *ResourceConfig) (ws []string, es []error) {
expected := "aws_instance"
if rt != expected {
t.Fatalf("expected: %s, got: %s", expected, rt)
}
expected = "bar"
val, _ := c.Get("foo")
if val != expected {
t.Fatalf("expected: %s, got: %s", expected, val)
}
return
}
p := ResourceProvider(mp)
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{
"foo": cty.StringVal("bar"),
}),
}
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
node := &EvalValidateResource{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Addr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
},
Provider: &p,
Config: rc,
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
_, err := node.Eval(&MockEvalContext{})
if err != nil {
t.Fatalf("err: %s", err)
}
if !mp.ValidateResourceCalled {
t.Fatal("Expected ValidateResource to be called, but it was not!")
}
}
func TestEvalValidateResource_dataSource(t *testing.T) {
mp := testProvider("aws")
mp.ValidateDataSourceFn = func(rt string, c *ResourceConfig) (ws []string, es []error) {
expected := "aws_ami"
if rt != expected {
t.Fatalf("expected: %s, got: %s", expected, rt)
}
expected = "bar"
val, _ := c.Get("foo")
if val != expected {
t.Fatalf("expected: %s, got: %s", expected, val)
}
return
}
p := ResourceProvider(mp)
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
rc := &configs.Resource{
Mode: addrs.DataResourceMode,
Type: "aws_ami",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{
"foo": cty.StringVal("bar"),
}),
}
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
node := &EvalValidateResource{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Addr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.DataResourceMode,
Type: "aws_ami",
Name: "foo",
},
},
Provider: &p,
Config: rc,
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
_, err := node.Eval(&MockEvalContext{})
if err != nil {
t.Fatalf("err: %s", err)
}
if !mp.ValidateDataSourceCalled {
t.Fatal("Expected ValidateDataSource to be called, but it was not!")
}
}
func TestEvalValidateResource_validReturnsNilError(t *testing.T) {
mp := testProvider("aws")
mp.ValidateResourceFn = func(rt string, c *ResourceConfig) (ws []string, es []error) {
return
}
p := ResourceProvider(mp)
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{}),
}
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
node := &EvalValidateResource{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Addr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
},
Provider: &p,
Config: rc,
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
_, err := node.Eval(&MockEvalContext{})
if err != nil {
t.Fatalf("Expected nil error, got: %s", err)
}
}
func TestEvalValidateResource_warningsAndErrorsPassedThrough(t *testing.T) {
mp := testProvider("aws")
mp.ValidateResourceFn = func(rt string, c *ResourceConfig) (ws []string, es []error) {
ws = append(ws, "warn")
es = append(es, errors.New("err"))
return
}
p := ResourceProvider(mp)
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{}),
}
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
node := &EvalValidateResource{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Addr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
},
Provider: &p,
Config: rc,
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
_, err := node.Eval(&MockEvalContext{})
if err == nil {
t.Fatal("Expected an error, got none!")
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
var diags tfdiags.Diagnostics
diags = diags.Append(err)
bySeverity := map[tfdiags.Severity]tfdiags.Diagnostics{}
for _, diag := range diags {
bySeverity[diag.Severity()] = append(bySeverity[diag.Severity()], diag)
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if len(bySeverity[tfdiags.Warning]) != 1 || bySeverity[tfdiags.Warning][0].Description().Summary != "warn" {
t.Fatalf("Expected 1 warning 'warn', got: %#v", bySeverity[tfdiags.Warning])
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if len(bySeverity[tfdiags.Error]) != 1 || bySeverity[tfdiags.Error][0].Description().Summary != "err" {
t.Fatalf("Expected 1 error 'err', got: %#v", bySeverity[tfdiags.Error])
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
}
}
func TestEvalValidateResource_ignoreWarnings(t *testing.T) {
mp := testProvider("aws")
mp.ValidateResourceFn = func(rt string, c *ResourceConfig) (ws []string, es []error) {
ws = append(ws, "warn")
return
}
p := ResourceProvider(mp)
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{}),
}
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
node := &EvalValidateResource{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Addr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
},
Provider: &p,
Config: rc,
core: rerun resource validation before plan and apply In #7170 we found two scenarios where the type checking done during the `context.Validate()` graph walk was circumvented, and the subsequent assumption of type safety in the provider's `Diff()` implementation caused panics. Both scenarios have to do with interpolations that reference Computed values. The sentinel we use to indicate that a value is Computed does not carry any type information with it yet. That means that an incorrect reference to a list or a map in a string attribute can "sneak through" validation only to crop up... 1. ...during Plan for Data Source References 2. ...during Apply for Resource references In order to address this, we: * add high-level tests for each of these two scenarios in `provider/test` * add context-level tests for the same two scenarios in `terraform` (these tests proved _really_ tricky to write!) * place an `EvalValidateResource` just before `EvalDiff` and `EvalApply` to catch these errors * add some plumbing to `Plan()` and `Apply()` to return validation errors, which were previously only generated during `Validate()` * wrap unit-tests around `EvalValidateResource` * add an `IgnoreWarnings` option to `EvalValidateResource` to prevent active warnings from halting execution on the second-pass validation Eventually, we might be able to attach type information to Computed values, which would allow for these errors to be caught earlier. For now, this solution keeps us safe from panics and raises the proper errors to the user. Fixes #7170
2016-06-30 18:22:20 -05:00
IgnoreWarnings: true,
}
_, err := node.Eval(&MockEvalContext{})
if err != nil {
t.Fatalf("Expected no error, got: %s", err)
}
}
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
func TestEvalValidateProvisioner_valid(t *testing.T) {
mp := &MockResourceProvisioner{}
var p ResourceProvisioner = mp
ctx := &MockEvalContext{}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
schema := &configschema.Block{}
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
node := &EvalValidateProvisioner{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
ResourceAddr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
Provisioner: &p,
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Schema: &schema,
Config: &configs.Provisioner{
Type: "baz",
Config: hcl.EmptyBody(),
},
ConnConfig: &configs.Connection{
Type: "ssh",
Config: hcl.EmptyBody(),
},
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
result, err := node.Eval(ctx)
if err != nil {
t.Fatalf("node.Eval failed: %s", err)
}
if result != nil {
t.Errorf("node.Eval returned non-nil result")
}
if !mp.ValidateCalled {
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
t.Fatalf("p.Validate not called")
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
}
func TestEvalValidateProvisioner_warning(t *testing.T) {
mp := &MockResourceProvisioner{}
var p ResourceProvisioner = mp
ctx := &MockEvalContext{}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
schema := &configschema.Block{}
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
node := &EvalValidateProvisioner{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
ResourceAddr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
Provisioner: &p,
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Schema: &schema,
Config: &configs.Provisioner{
Type: "baz",
Config: hcl.EmptyBody(),
},
ConnConfig: &configs.Connection{
Type: "ssh",
Config: hcl.EmptyBody(),
},
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
mp.ValidateReturnWarns = []string{"foo is deprecated"}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
_, err := node.Eval(ctx)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
if err == nil {
t.Fatalf("node.Eval succeeded; want error")
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
var diags tfdiags.Diagnostics
diags = diags.Append(err)
if len(diags) != 1 {
t.Fatalf("wrong number of diagsnostics in %#v; want one warning", diags)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if got, want := diags[0].Description().Summary, mp.ValidateReturnWarns[0]; got != want {
t.Fatalf("wrong warning %q; want %q", got, want)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
}
func TestEvalValidateProvisioner_connectionInvalid(t *testing.T) {
var p ResourceProvisioner = &MockResourceProvisioner{}
ctx := &MockEvalContext{}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
schema := &configschema.Block{}
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
node := &EvalValidateProvisioner{
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
ResourceAddr: addrs.ResourceInstance{
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
Provisioner: &p,
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Schema: &schema,
Config: &configs.Provisioner{
Type: "baz",
Config: hcl.EmptyBody(),
},
ConnConfig: &configs.Connection{
Type: "ssh",
Config: configs.SynthBody("", map[string]cty.Value{
"bananananananana": cty.StringVal("foo"),
"bazaz": cty.StringVal("bar"),
}),
},
}
_, err := node.Eval(ctx)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
if err == nil {
t.Fatalf("node.Eval succeeded; want error")
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
var diags tfdiags.Diagnostics
diags = diags.Append(err)
if len(diags) != 2 {
t.Fatalf("wrong number of diagsnostics in %#v; want two errors", diags)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
errStr := diags.Err().Error()
if !(strings.Contains(errStr, "bananananananana") && strings.Contains(errStr, "bazaz")) {
t.Fatalf("wrong errors %q; want something about each of our invalid connInfo keys", errStr)
Detect and reject unknown attributes in "connection" blocks Since the validation of connection blocks is delegated to the communicator selected by "type", we were not previously doing any validation of the attribute names in these blocks until running provisioners during apply. Proper validation here requires us to already have the instance state, since the final connection info is a merge of values provided in config with values assigned automatically by the resource. However, we can do some basic name validation to catch typos during the validation pass, even though semantic validation and checking for missing attributes will still wait until the provisioner is instantiated. This fixes #6582 as much as we reasonably can.
2017-04-05 17:34:59 -05:00
}
}
Reference in New Issue Copy Permalink