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

523 lines
14 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"
vendor: switch to HCL 2.0 in the HCL repository Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.
2019-09-09 17:58:44 -05:00
"github.com/hashicorp/hcl/v2"
"github.com/hashicorp/hcl/v2/hcltest"
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/zclconf/go-cty/cty"
"github.com/hashicorp/terraform/addrs"
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
"github.com/hashicorp/terraform/configs"
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
"github.com/hashicorp/terraform/configs/configschema"
"github.com/hashicorp/terraform/providers"
"github.com/hashicorp/terraform/provisioners"
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
"github.com/hashicorp/terraform/tfdiags"
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) {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
if got, want := req.TypeName, "test_object"; got != want {
t.Fatalf("wrong resource type\ngot: %#v\nwant: %#v", got, want)
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if got, want := req.Config.GetAttr("test_string"), cty.StringVal("bar"); !got.RawEquals(want) {
t.Fatalf("wrong value for test_string\ngot: %#v\nwant: %#v", got, want)
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
return providers.ValidateResourceTypeConfigResponse{}
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
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(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,
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Type: "test_object",
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
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
"test_string": cty.StringVal("bar"),
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
}),
}
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
}
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
if err != nil {
t.Fatalf("err: %s", err)
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if !mp.ValidateResourceTypeConfigCalled {
t.Fatal("Expected ValidateResourceTypeConfig to be called, but it was not!")
core: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
}
}
func TestEvalValidateResource_managedResourceCount(t *testing.T) {
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
if got, want := req.TypeName, "test_object"; got != want {
t.Fatalf("wrong resource type\ngot: %#v\nwant: %#v", got, want)
core: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if got, want := req.Config.GetAttr("test_string"), cty.StringVal("bar"); !got.RawEquals(want) {
t.Fatalf("wrong value for test_string\ngot: %#v\nwant: %#v", got, want)
core: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
return providers.ValidateResourceTypeConfigResponse{}
core: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(mp)
core: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "foo",
Count: hcltest.MockExprLiteral(cty.NumberIntVal(2)),
Config: configs.SynthBody("", map[string]cty.Value{
"test_string": cty.StringVal("bar"),
}),
}
node := &EvalValidateResource{
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
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
},
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
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: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
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
if err != nil {
t.Fatalf("err: %s", err)
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if !mp.ValidateResourceTypeConfigCalled {
t.Fatal("Expected ValidateResourceTypeConfig to be called, but it was not!")
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_dataSource(t *testing.T) {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateDataSourceConfigFn = func(req providers.ValidateDataSourceConfigRequest) providers.ValidateDataSourceConfigResponse {
if got, want := req.TypeName, "test_object"; got != want {
t.Fatalf("wrong resource type\ngot: %#v\nwant: %#v", got, want)
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if got, want := req.Config.GetAttr("test_string"), cty.StringVal("bar"); !got.RawEquals(want) {
t.Fatalf("wrong value for test_string\ngot: %#v\nwant: %#v", got, want)
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
return providers.ValidateDataSourceConfigResponse{}
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
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(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,
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Type: "test_object",
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
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
"test_string": cty.StringVal("bar"),
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
}),
}
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
Addr: addrs.Resource{
Mode: addrs.DataResourceMode,
Type: "aws_ami",
Name: "foo",
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
},
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
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: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
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
if err != nil {
t.Fatalf("err: %s", err)
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if !mp.ValidateDataSourceConfigCalled {
t.Fatal("Expected ValidateDataSourceConfig to be called, but it was not!")
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_validReturnsNilError(t *testing.T) {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
return providers.ValidateResourceTypeConfigResponse{}
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
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(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,
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Type: "test_object",
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
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "foo",
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
},
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
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: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
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
if err != nil {
t.Fatalf("Expected nil error, got: %s", err)
}
}
func TestEvalValidateResource_warningsAndErrorsPassedThrough(t *testing.T) {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
var diags tfdiags.Diagnostics
diags = diags.Append(tfdiags.SimpleWarning("warn"))
diags = diags.Append(errors.New("err"))
return providers.ValidateResourceTypeConfigResponse{
Diagnostics: diags,
}
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
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(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,
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Type: "test_object",
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
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "foo",
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
},
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
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: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
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
if err == nil {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
t.Fatal("unexpected success; want 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
}
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" {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
t.Errorf("Expected 1 warning 'warn', got: %s", bySeverity[tfdiags.Warning].ErrWithWarnings())
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" {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
t.Errorf("Expected 1 error 'err', got: %s", bySeverity[tfdiags.Error].Err())
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) {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
var diags tfdiags.Diagnostics
diags = diags.Append(tfdiags.SimpleWarning("warn"))
return providers.ValidateResourceTypeConfigResponse{
Diagnostics: diags,
}
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
}
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(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,
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Type: "test_object",
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
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test-object",
Name: "foo",
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
},
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
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,
}
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
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
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
core: validate that depends_on addresses are for objects Since the "References" function on graph nodes can't return errors, we need to catch invalid depends_on references during the validation pass. In this case, we're checking that the address is exact, rather than being part of a traversal into an attribute of the object. In other words, aws_instance.example is valid but aws_instance.example.id is not.
2018-07-02 12:23:41 -05:00
func TestEvalValidateResource_invalidDependsOn(t *testing.T) {
mp := simpleMockProvider()
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
mp.ValidateResourceTypeConfigFn = func(req providers.ValidateResourceTypeConfigRequest) providers.ValidateResourceTypeConfigResponse {
return providers.ValidateResourceTypeConfigResponse{}
core: validate that depends_on addresses are for objects Since the "References" function on graph nodes can't return errors, we need to catch invalid depends_on references during the validation pass. In this case, we're checking that the address is exact, rather than being part of a traversal into an attribute of the object. In other words, aws_instance.example is valid but aws_instance.example.id is not.
2018-07-02 12:23:41 -05:00
}
// We'll check a _valid_ config first, to make sure we're not failing
// for some other reason, and then make it invalid.
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
p := providers.Interface(mp)
core: validate that depends_on addresses are for objects Since the "References" function on graph nodes can't return errors, we need to catch invalid depends_on references during the validation pass. In this case, we're checking that the address is exact, rather than being part of a traversal into an attribute of the object. In other words, aws_instance.example is valid but aws_instance.example.id is not.
2018-07-02 12:23:41 -05:00
rc := &configs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "foo",
Config: configs.SynthBody("", map[string]cty.Value{}),
DependsOn: []hcl.Traversal{
// Depending on path.module is pointless, since it is immediately
// available, but we allow all of the referencable addrs here
// for consistency: referencing them is harmless, and avoids the
// need for us to document a different subset of addresses that
// are valid in depends_on.
// For the sake of this test, it's a valid address we can use that
// doesn't require something else to exist in the configuration.
{
hcl.TraverseRoot{
Name: "path",
},
hcl.TraverseAttr{
Name: "module",
},
},
},
}
node := &EvalValidateResource{
Addr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "aws_instance",
Name: "foo",
},
Provider: &p,
Config: rc,
ProviderSchema: &mp.GetSchemaReturn,
}
ctx := &MockEvalContext{}
ctx.installSimpleEval()
_, err := node.Eval(ctx)
if err != nil {
t.Fatalf("error for supposedly-valid config: %s", err)
}
core: Fix panic on invalid depends_on root. (#21589) Report an invalid reference to the user instead of crashing when there is in error traversing the `depends_on` attribute. Fixes #21590
2019-06-06 07:43:22 -05:00
// Now we'll make it invalid by adding additional traversal steps at
// the end of what we're referencing. This is intended to catch the
core: validate that depends_on addresses are for objects Since the "References" function on graph nodes can't return errors, we need to catch invalid depends_on references during the validation pass. In this case, we're checking that the address is exact, rather than being part of a traversal into an attribute of the object. In other words, aws_instance.example is valid but aws_instance.example.id is not.
2018-07-02 12:23:41 -05:00
// situation where the user tries to depend on e.g. a specific resource
// attribute, rather than the whole resource, like aws_instance.foo.id.
rc.DependsOn = append(rc.DependsOn, hcl.Traversal{
hcl.TraverseRoot{
Name: "path",
},
hcl.TraverseAttr{
Name: "module",
},
hcl.TraverseAttr{
Name: "extra",
},
})
_, err = node.Eval(ctx)
if err == nil {
t.Fatal("no error for invalid depends_on")
}
if got, want := err.Error(), "Invalid depends_on reference"; !strings.Contains(got, want) {
t.Fatalf("wrong error\ngot: %s\nwant: Message containing %q", got, want)
}
core: Fix panic on invalid depends_on root. (#21589) Report an invalid reference to the user instead of crashing when there is in error traversing the `depends_on` attribute. Fixes #21590
2019-06-06 07:43:22 -05:00
// Test for handling an unknown root without attribute, like a
// typo that omits the dot inbetween "path.module".
rc.DependsOn = append(rc.DependsOn, hcl.Traversal{
hcl.TraverseRoot{
Name: "pathmodule",
},
})
_, err = node.Eval(ctx)
if err == nil {
t.Fatal("no error for invalid depends_on")
}
if got, want := err.Error(), "Invalid depends_on reference"; !strings.Contains(got, want) {
t.Fatalf("wrong error\ngot: %s\nwant: Message containing %q", got, want)
}
core: validate that depends_on addresses are for objects Since the "References" function on graph nodes can't return errors, we need to catch invalid depends_on references during the validation pass. In this case, we're checking that the address is exact, rather than being part of a traversal into an attribute of the object. In other words, aws_instance.example is valid but aws_instance.example.id is not.
2018-07-02 12:23:41 -05:00
}
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) {
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
mp := &MockProvisioner{}
var p provisioners.Interface = mp
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
ctx := &MockEvalContext{}
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx.installSimpleEval()
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
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
ResourceAddr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
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
},
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(),
merge connection blocks for validation The resource connection block was not being validated. Merge the two bodies, with the provider as the override, before validation.
2019-03-26 08:11:43 -05:00
Connection: &configs.Connection{
Config: configs.SynthBody("", map[string]cty.Value{
"host": cty.StringVal("localhost"),
"type": cty.StringVal("ssh"),
}),
},
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
},
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")
}
core: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if !mp.ValidateProvisionerConfigCalled {
t.Fatalf("p.ValidateProvisionerConfig 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) {
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
mp := &MockProvisioner{}
var p provisioners.Interface = mp
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
ctx := &MockEvalContext{}
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx.installSimpleEval()
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
fix the provisioner schema and update tests The provisioenr schema needed to have `Optional: true` for all the attributes. Also add the `type` attr and update the tests to match.
2018-05-29 14:00:16 -05:00
schema := &configschema.Block{
Attributes: map[string]*configschema.Attribute{
"type": {
Type: cty.String,
Optional: true,
},
},
}
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
ResourceAddr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
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
},
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(),
merge connection blocks for validation The resource connection block was not being validated. Merge the two bodies, with the provider as the override, before validation.
2019-03-26 08:11:43 -05:00
Connection: &configs.Connection{
Config: configs.SynthBody("", map[string]cty.Value{
"host": cty.StringVal("localhost"),
"type": cty.StringVal("ssh"),
}),
},
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
},
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
{
var diags tfdiags.Diagnostics
diags = diags.Append(tfdiags.SimpleWarning("foo is deprecated"))
mp.ValidateProvisionerConfigResponse = provisioners.ValidateProvisionerConfigResponse{
Diagnostics: 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
_, 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 {
fix provisioner tests Add host where required in the test configs, and fix the mock to check for a null connection.
2018-12-19 14:23:29 -06:00
t.Fatalf("wrong number of diagnostics in %s; want one warning", diags.ErrWithWarnings())
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: Fix various compile-time errors in tests Significant changes to the provider interface left a lot of the tests in a non-buildable state. This set of changes gets the tests building again but does not attempt to make them run to completion or pass. After this commit, it is possible to build a test program for the ./terraform package but it will panic during its run. That will be addressed in subsequent commits.
2018-09-05 16:35:30 -05:00
if got, want := diags[0].Description().Summary, mp.ValidateProvisionerConfigResponse.Diagnostics[0].Description().Summary; got != want {
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("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) {
replace provider and provisioner types in tests The field assignments and methods are incorrect still, but the type definitions and returns are now updated.
2018-08-17 14:32:35 -05:00
var p provisioners.Interface = &MockProvisioner{}
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
ctx := &MockEvalContext{}
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
ctx.installSimpleEval()
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
fix the provisioner schema and update tests The provisioenr schema needed to have `Optional: true` for all the attributes. Also add the `type` attr and update the tests to match.
2018-05-29 14:00:16 -05:00
schema := &configschema.Block{
Attributes: map[string]*configschema.Attribute{
"type": {
Type: cty.String,
Optional: true,
},
},
}
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: Don't DynamicExpand during validate Previously we would attempt to DynamicExpand during the validate walk and then validate each expanded instance separately. However, this meant that we would not be able to validate the contents of a block where count = 0 or if count is not yet known. Here we instead do a more static validation pass against the resource configuration itself, setting count.index to cty.UnknownVal(cty.Number) so we can type-check everything inside the block as being correct regardless of the final count. This is another step towards repairing the "validate" command for our changed assumptions in a world where we have a more sophisticated type checker. This doesn't yet address the remaining problem that the expression evaluator can't, with the current state structures, distinguish between a completed resource with count = 0 and a resource that doesn't exist at all (during validate), and so we'll still get errors if an expression elsewhere in configuration refers to a dynamic index of a resource with "count" set. That's a pre-existing condition that's no longer being masked by _this_ problem, but can't be addressed until we've introduced the new state types (states.State, etc) and thus we _can_ distinguish these two situations. That will therefore be addressed in a later commit.
2018-06-22 18:54:27 -05:00
ResourceAddr: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "foo",
Name: "bar",
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
},
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(),
merge connection blocks for validation The resource connection block was not being validated. Merge the two bodies, with the provider as the override, before validation.
2019-03-26 08:11:43 -05:00
Connection: &configs.Connection{
Config: configs.SynthBody("", map[string]cty.Value{
"type": cty.StringVal("ssh"),
"bananananananana": cty.StringVal("foo"),
"bazaz": cty.StringVal("bar"),
}),
},
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)
fix provisioner tests Add host where required in the test configs, and fix the mock to check for a null connection.
2018-12-19 14:23:29 -06:00
if len(diags) != 3 {
core: Fix tests for types in eval_validate.go A schema is now required for any validation, so these tests now use the simpleMockProvider function to produce a provider with a simple schema already configured, and test against that schema.
2018-05-10 19:48:43 -05:00
t.Fatalf("wrong number of diagnostics; want two errors\n\n%s", diags.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
}
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