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

60 lines
2.3 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,
},
},
Add support for provider metadata to modules. (#22583) Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>
2020-03-06 01:53:24 +01:00
ProviderMetaSchema: map[string]*schema.Schema{
// Optionally allow specifying information at a module-level
"foo": {
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(),
"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(),
Add support for provider metadata to modules. (#22583) Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>
2020-03-06 01:53:24 +01:00
"test_resource_provider_meta": testResourceProviderMeta(),
command: Unmanaged providers This adds supports for "unmanaged" providers, or providers with process lifecycles not controlled by Terraform. These providers are assumed to be started before Terraform is launched, and are assumed to shut themselves down after Terraform has finished running. To do this, we must update the go-plugin dependency to v1.3.0, which added support for the "test mode" plugin serving that powers all this. As a side-effect of not needing to manage the process lifecycle anymore, Terraform also no longer needs to worry about the provider's binary, as it won't be used for anything anymore. Because of this, we can disable the init behavior that concerns itself with downloading that provider's binary, checking its version, and otherwise managing the binary. This is all managed on a per-provider basis, so managed providers that Terraform downloads, starts, and stops can be used in the same commands as unmanaged providers. The TF_REATTACH_PROVIDERS environment variable is added, and is a JSON encoding of the provider's address to the information we need to connect to it. This change enables two benefits: first, delve and other debuggers can now be attached to provider server processes, and Terraform can connect. This allows for attaching debuggers to provider processes, which before was difficult to impossible. Second, it allows the SDK test framework to host the provider in the same process as the test driver, while running a production Terraform binary against the provider. This allows for Go's built-in race detector and test coverage tooling to work as expected in provider tests. Unmanaged providers are expected to work in the exact same way as managed providers, with one caveat: Terraform kills provider processes and restarts them once per graph walk, meaning multiple times during most Terraform CLI commands. As unmanaged providers can't be killed by Terraform, and have no visibility into graph walks, unmanaged providers are likely to have differences in how their global mutable state behaves when compared to managed providers. Namely, unmanaged providers are likely to retain global state when managed providers would have reset it. Developers relying on global state should be aware of this.
2020-05-27 02:48:57 +02:00
"test_resource_signal": testResourceSignal(),
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
}