resilien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terraform/builtin/providers/test/provider.go

53 lines
2.1 KiB
Go
Raw Normal View History

provider/test: a test provider Here we also introduce a `test` provider meant as an aid to exposing via automated tests issues involving interactions between `helper/schema` and Terraform core. This has been helpful so far in diagnosing `ignore_changes` problems, and I imagine it will be helpful in other contexts as well. We'll have to be careful to prevent the `test` provider from becoming a dumping ground for poorly specified tests that have a clear home elsewhere. But for bug exposure I think it's useful to have.
2016-03-15 16:11:28 +01:00
package test
import (
"github.com/hashicorp/terraform/helper/schema"
"github.com/hashicorp/terraform/terraform"
)
func Provider() terraform.ResourceProvider {
return &schema.Provider{
provider/test: allow assigning a label to each instance When testing the behavior of multiple provider instances (either aliases or child module overrides) it's convenient to be able to label the individual instances to determine which one is actually being used for the purpose of making test assertions.
2017-05-09 20:47:22 +02:00
Schema: map[string]*schema.Schema{
// Optional attribute to label a particular instance for a test
// that has multiple instances of this provider, so that they
// can be distinguished using the test_provider_label data source.
"label": {
Type: schema.TypeString,
Optional: true,
},
},
provider/test: a test provider Here we also introduce a `test` provider meant as an aid to exposing via automated tests issues involving interactions between `helper/schema` and Terraform core. This has been helpful so far in diagnosing `ignore_changes` problems, and I imagine it will be helpful in other contexts as well. We'll have to be careful to prevent the `test` provider from becoming a dumping ground for poorly specified tests that have a clear home elsewhere. But for bug exposure I think it's useful to have.
2016-03-15 16:11:28 +01:00
ResourcesMap: map[string]*schema.Resource{
helper/schema: Hook CustomizeDiffFunc into diff logic It's alive! CustomizeDiff logic now has been inserted into the diff process. The test_resource_with_custom_diff resource provides some basic testing and a reference implementation. There should now be plenty of test coverage for this feature via the tests added for ResourceDiff, and the basic test added to the schemaMap.Diff test, and the test resource, but more can be added to test any specific case that comes up otherwise.
2017-05-28 07:58:44 +02:00
"test_resource": testResource(),
"test_resource_gh12183": testResourceGH12183(),
helper/plugin: Honor resource type overrides in import One quirky aspect of our import feature is that we allow the importer to produce additional resources alongside the one that was imported, such as to create separate rules for each rule of an imported security group. Providers need to be able to set the types of these other resources since they may not match the "main" resource type. They do this by calling ResourceData.SetType, which in turn sets InstanceState.Ephemeral.Type. In our shims here we therefore need to copy that out into our new TypeName field so that the new core import code can see it and create the right type in the state. Testing this required a minor change to the test harness to allow the ImportStateCheck function to see the resource type.
2019-01-30 01:49:02 +01:00
"test_resource_import_other": testResourceImportOther(),
helper/resource: Ignore Removed attributes for ImportStateVerify Due to the lossiness of our legacy models for diff and state, shimming a diff and then creating a state from it produces a different result than shimming a state directly. That means that ImportStateVerify no longer works as expected if there are any Computed attributes in the schema where d.Set isn't called during Read. Fixing that for every case would require some risky changes to the shim behavior, so we're instead going to ask provider developers to address it by adding `d.Set` calls where needed, since that is the contract for "Computed" anyway -- a default value should be produced during Create, and thus by extension during Import. However, since a common situation where this occurs is attributes marked as "Removed", since all of the code that deals with them has generally been deleted, we'll avoid problems in that case here by treating Removed attributes as ignored for the purposes of ImportStateVerify. This required exporting some functionality that was formerly unexported in helper/schema, but it's a relatively harmless schema introspection function so shouldn't be a big deal to export it.
2019-04-16 02:54:06 +02:00
"test_resource_import_removed": testResourceImportRemoved(),
helper/schema: Hook CustomizeDiffFunc into diff logic It's alive! CustomizeDiff logic now has been inserted into the diff process. The test_resource_with_custom_diff resource provides some basic testing and a reference implementation. There should now be plenty of test coverage for this feature via the tests added for ResourceDiff, and the basic test added to the schemaMap.Diff test, and the test resource, but more can be added to test any specific case that comes up otherwise.
2017-05-28 07:58:44 +02:00
"test_resource_with_custom_diff": testResourceCustomDiff(),
add timeout tests to the test provider
2018-10-30 17:58:29 +01:00
"test_resource_timeout": testResourceTimeout(),
add provider tests for SuppressDiffFunc
2018-10-30 19:53:02 +01:00
"test_resource_diff_suppress": testResourceDiffSuppress(),
add provider tests for force-new with a map Adding and removing a single map that requires a new resource can cause empty diffs, relying on the core proposed state values for destruction.
2018-10-31 18:42:28 +01:00
"test_resource_force_new": testResourceForceNew(),
test case for optional bools in schema Booleans in the legacy form were stored as strings, and can appear as the incorrect type in the new type system. Unset fields in sets also might show up erroneously in diffs, with equal old and new values.
2018-11-01 21:11:19 +01:00
"test_resource_nested": testResourceNested(),
failing test for schemas with a single set attr Resources with certain combinations of attributes in a nested single set fail to perperly coerce their shimmed values.
2018-11-08 18:15:06 +01:00
"test_resource_nested_set": testResourceNestedSet(),
StateFunc tests
2018-12-03 18:47:17 +01:00
"test_resource_state_func": testResourceStateFunc(),
add tests for deprecated/removed attrs
2019-01-11 23:36:46 +01:00
"test_resource_deprecated": testResourceDeprecated(),
add tests for nested default values Don't lose default values set within a nested block.
2019-01-16 22:54:02 +01:00
"test_resource_defaults": testResourceDefaults(),
add failing test for lost elements in list blocks Modifying an element loses the modification, and other elements in a TypeList.
2019-01-18 19:05:59 +01:00
"test_resource_list": testResourceList(),
add failing test for set elements with custom diff Adding a DiffSuppressFunc for set elements can cause them to be missed in the set diff entirely.
2019-02-02 03:34:12 +01:00
"test_resource_list_set": testResourceListSet(),
test for missing map entries
2019-01-23 22:33:19 +01:00
"test_resource_map": testResourceMap(),
add computed set test with CustomizeDiff
2019-02-01 23:07:56 +01:00
"test_resource_computed_set": testResourceComputedSet(),
helper/schema: Honor ConfigMode when building core schema This makes some slight adjustments to the shape of the schema we present to Terraform Core without affecting how it is consumed by the SDK and thus the provider. This mechanism is designed specifically to avoid changing how the schema is interpreted by the SDK itself or by the provider, so that prior behavior can be preserved in Terraform v0.11 mode. This also includes a new rule that Computed-only (i.e. not also Optional) schemas _always_ map to attributes, because that is a better mapping of the intent: they are object values to be used in expressions. Nested blocks conceptually represent nested objects that are in some sense independent of what they are embedded in, and so they cannot themselves be computed.
2019-03-09 01:31:22 +01:00
"test_resource_config_mode": testResourceConfigMode(),
only force top-level id's back to unknown Nested structures may have "id" fields, which should be treated normally.
2019-02-05 22:16:08 +01:00
"test_resource_nested_id": testResourceNestedId(),
core: Keep old value on error even for delete When an operation fails, providers may return a null new value rather than returning a partial state. In that case, we'd prefer to keep the old value so that we stand the best chance of being able to retry on a subsequent run. Previously we were making an exception for the delete action, allowing the result of that to be null even when an error is returned. In practice that was a bad idea because it would cause Terraform to lose track of the object even though it might not actually have been deleted. Now we'll retain the old object even in the delete case. Providers can still return partial new objects if they were able to partially complete a delete operation, in which case we'll discard what we had before, but if the result is null with errors then we'll assume the delete failed entirely and so just keep the old state as-is, giving us the opportunity to refresh it on the next run to see if anything actually happened after all. (This also includes a new resource in the test provider which isn't used by the patch but was useful for some manual UX testing here, so I thought I'd include it in case it's similarly useful in future, given how simple its implementation is.)
2019-04-17 01:46:26 +02:00
"test_undeleteable": testResourceUndeleteable(),
test for Required win MinItems > 1
2019-07-26 23:36:19 +02:00
"test_resource_required_min": testResourceRequiredMin(),
provider/test: a test provider Here we also introduce a `test` provider meant as an aid to exposing via automated tests issues involving interactions between `helper/schema` and Terraform core. This has been helpful so far in diagnosing `ignore_changes` problems, and I imagine it will be helpful in other contexts as well. We'll have to be careful to prevent the `test` provider from becoming a dumping ground for poorly specified tests that have a clear home elsewhere. But for bug exposure I think it's useful to have.
2016-03-15 16:11:28 +01: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-07-01 01:22:20 +02:00
DataSourcesMap: map[string]*schema.Resource{
provider/test: allow assigning a label to each instance When testing the behavior of multiple provider instances (either aliases or child module overrides) it's convenient to be able to label the individual instances to determine which one is actually being used for the purpose of making test assertions.
2017-05-09 20:47:22 +02:00
"test_data_source": testDataSource(),
"test_provider_label": providerLabelDataSource(),
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-07-01 01:22:20 +02:00
},
provider/test: a test provider Here we also introduce a `test` provider meant as an aid to exposing via automated tests issues involving interactions between `helper/schema` and Terraform core. This has been helpful so far in diagnosing `ignore_changes` problems, and I imagine it will be helpful in other contexts as well. We'll have to be careful to prevent the `test` provider from becoming a dumping ground for poorly specified tests that have a clear home elsewhere. But for bug exposure I think it's useful to have.
2016-03-15 16:11:28 +01:00
ConfigureFunc: providerConfigure,
}
}
func providerConfigure(d *schema.ResourceData) (interface{}, error) {
provider/test: allow assigning a label to each instance When testing the behavior of multiple provider instances (either aliases or child module overrides) it's convenient to be able to label the individual instances to determine which one is actually being used for the purpose of making test assertions.
2017-05-09 20:47:22 +02:00
return d.Get("label"), nil
provider/test: a test provider Here we also introduce a `test` provider meant as an aid to exposing via automated tests issues involving interactions between `helper/schema` and Terraform core. This has been helpful so far in diagnosing `ignore_changes` problems, and I imagine it will be helpful in other contexts as well. We'll have to be careful to prevent the `test` provider from becoming a dumping ground for poorly specified tests that have a clear home elsewhere. But for bug exposure I think it's useful to have.
2016-03-15 16:11:28 +01:00
}