This project is mirrored from https://:*****@github.com/hashicorp/terraform.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 26 Jan, 2021 1 commit
-
-
Jonathan Hall authored
-
- 02 Dec, 2020 1 commit
-
-
James Bardin authored
moving helper/schema into the ineternal/legacy tree
-
- 08 Aug, 2019 1 commit
-
-
Radek Simko authored
-
- 06 Aug, 2019 1 commit
-
-
Alex Pilon authored
-
- 30 Jul, 2019 1 commit
-
-
Kristin Laemmert authored
If an attribute was not wholly known, helper/schema was skipping the `validateType` function which (among other things) returned deprecation messages. This PR checks for deprecation before returning when skipping validateType.
-
- 29 Jul, 2019 1 commit
-
-
James Bardin authored
Nil values were not previously expected during validation, but they can appear in some situations with the new protocol. Add checks to prevent using zero reflect.Values.
-
- 27 Jul, 2019 1 commit
-
-
James Bardin authored
If there are unknowns, the block may have come from a dynamic declaration, and we can't validate MinItems. Once the blocks are expanded, we will get the full config for validation without any unknown values.
-
- 18 Jul, 2019 1 commit
-
-
Alex Pilon authored
-
- 28 May, 2019 1 commit
-
-
James Bardin authored
While there was already a check in the sdk to filter unknowns from validation, it missed the case where those were in simple lists and maps.
-
- 14 May, 2019 1 commit
-
-
James Bardin authored
This experiment is no longer needed for handling computed blocks, since the legacy SDK can't reasonably handle Dynamic types, we need to remove this before the final release. Remove LegacySchema functions as well, since handling SkipCoreTypeCheck was the only thing left they were handling.
-
- 11 May, 2019 1 commit
-
-
James Bardin authored
The new type system only has a Number type, but helper schema differentiates between Int and Float values. Verify that a new config value is an integer during Validate, because the existing WeakDecode validation will decode a float value into an integer while the config FieldReader will attempt to parse the float exactly. Since we're limiting this to protoV5, we can be certain that any valid config value will be converted to an `int` type by the shims. The only case where an integral float value will appear is if the integer is out of range for the systems `int` type, but we also need to prevent that anyway since it would fail to read in the same manner.
-
- 17 Apr, 2019 2 commits
-
-
Alex Somesan authored
-
Alex Somesan authored
-
- 08 Apr, 2019 1 commit
-
-
James Bardin authored
This reverts commit 4c0c74571de9c96ad2902ccf4af962ec495cd5d4.
-
- 29 Mar, 2019 1 commit
-
-
Alex Somesan authored
-
- 27 Mar, 2019 1 commit
-
-
Alex Somesan authored
-
- 21 Mar, 2019 1 commit
-
-
Martin Atkins authored
When running in v0.12-and-higher mode, this will cause the SDK to report the type of the attribute as "any", effectively skipping type checking on the Core side altogether and checking only in the SDK and provider code. The practical impact of this is to restore the v0.11-style checking behavior of allowing object values to be missing certain attributes as long as they are marked as optional in the schema. The SDK can do this because it uses a unified schema model for both object values and nested blocks, while Terraform Core only supports the idea of "optional" when talking about attributes in nested blocks. This is a continuation of the pile of workarounds that also includes the ConfigMode and AsSingle fields, allowing providers to selectively opt out of new v0.12 behaviors in situations where they conflict with decisions made in the design of the providers in our old world where Terraform Core delegated _all_ validation to providers. This is designed as an opt-in so that we can limit its impact only to specific cases where it's needed and minimize the risk of regressions elsewhere. Providers should use this sparingly only in situations where prevailing usage disagrees with the new expectations of Terraform Core in v0.12. This commit only adds the flag, and does not implement any behavior for it yet. That means this commit can exist in both the v0.11 and v0.12 codebases, allowing for API compatibility. A subsequent commit for v0.12 (not included in v0.11) will then implement this behavior.
-
- 18 Mar, 2019 2 commits
- 14 Mar, 2019 1 commit
-
-
Martin Atkins authored
This setting indicates that an attribute defined as TypeList or TypeSet should be presented to Terraform Core as a single value instead when running in Terraform v0.12 or later. It has no effect for Terraform v0.10 or v0.11. This commit just introduces the setting without any associated behavior, so it can be included in both the v0.12 and v0.11 branches. A subsequent commit only to the v0.12 branch will introduce the behavior as part of the protocol version 5 shims.
-
- 12 Mar, 2019 1 commit
-
-
Martin Atkins authored
This allows a provider developer slightly more control over how an SDK schema is mapped into the Terraform configuration language, overriding some default assumptions. ConfigMode overrides the default assumption that a schema with an Elem of type *Resource is to be mapped to configuration as a nested block, allowing mapping as an attribute containing an object type instead. These behaviors only apply when a provider is being used with Terraform v0.12 or later. They are ignored altogether in Terraform v0.11 mode, to preserve compatibility. We are adding these primarily to allow the v0.12 version of a resource type schema to be specified to match the prevailing usage of it in existing configurations, in situations where the default mapping to v0.12 concepts is not appropriate. This commit adds only the fields themselves and the InternalValidate rules for them. A subsequent commit for Terraform v0.12 will add the behavior as part of the protocol version 5 shim layer.
-
- 08 Mar, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 12 Feb, 2019 1 commit
-
-
Ryan King authored
This comment seems to imply that you can put CRUD functions on nested schema.Resource objects. The comment goes back to the first commit to this file, but AFAICT this functionality has never been implemented.
-
- 05 Feb, 2019 2 commits
-
-
James Bardin authored
Add feature flag to allow special proto 5 behavior in helper/schema. This is Meant to be used as a last resort for shim-related bugs.
-
James Bardin authored
Sets rely on diffs being complete for all elements, even when they are unchanged. When encountering a DiffSuppressFunc inside a set the diffs were being dropped entirely, possible causing set elements to be lost.
-
- 30 Jan, 2019 1 commit
-
-
Garfield Freeman authored
-
- 04 Jan, 2019 1 commit
-
-
Martin Atkins authored
With the introduction of explicit "null" in 0.12 it's possible for a value that is unknown during plan to become a known null during apply, so we need to slightly weaken our validation rules to accommodate that, in particular skipping the validation of conflicting attributes if the result could potentially be valid after the unknown values become known. This change is in the codepath that is common to both 0.12 and 0.11 callers, but that's safe because 0.11 re-runs validation during the apply step and so will still catch problems here, albeit in the apply step rather than in the plan step, thus matching the 0.12 behavior. This new behavior is a superset of the old in the sense that everything that was valid before is still valid. The implementation here also causes us to skip all other validation for an attribute whose value is unknown. Most of the downstream validation functions handle this directly anyway, but again this doesn't add any new failure cases, and should clean up some of the rough edges we've seen with unknown values in 0.11 once people upgrade to 0.12-compatible providers. Any issues we now short-circuit during planning will still be caught during apply. While working on this I found that the existing "Not a list" test was not actually testing the correct behavior, so this also includes a tweak to that to ensure that it really is checking the "should be a list" path rather than the "cannot be set" codepath it was inadvertently testing before.
-
- 05 Dec, 2018 1 commit
-
-
Brian Flad authored
When the following conditions were met: * Schema attribute with a primative type (e.g. Type: TypeString) and Computed: true * Old state of attribute set to zero value for type (e.g. "") * Old state ID of resource set to non-empty (e.g. existing resource) Attempting to use CustomizeDiff with SetNewComputed() would result in the difference previously being discarded. This update ensures that previous zero values or resource existence does not influence the propagation of the computed update. Previously: ``` --- FAIL: TestSetNewComputed (0.00s) --- FAIL: TestSetNewComputed/NewComputed_should_always_propagate (0.00s) resource_diff_test.go:684: Expected (*terraform.InstanceDiff)(0xc00051cea0)({ mu: (sync.Mutex) { state: (int32) 0, sema: (uint32) 0 }, Attributes: (map[string]*terraform.ResourceAttrDiff) (len=1) { (string) (len=3) "foo": (*terraform.ResourceAttrDiff)(0xc0003dcec0)({ Old: (string) "", New: (string) "", NewComputed: (bool) true, NewRemoved: (bool) false, NewExtra: (interface {}) <nil>, RequiresNew: (bool) false, Sensitive: (bool) false, Type: (terraform.DiffAttrType) 0 }) }, Destroy: (bool) false, DestroyDeposed: (bool) false, DestroyTainted: (bool) false, Meta: (map[string]interface {}) <nil> }) , got (*terraform.InstanceDiff)(0xc00051ce80)({ mu: (sync.Mutex) { state: (int32) 0, sema: (uint32) 0 }, Attributes: (map[string]*terraform.ResourceAttrDiff) { }, Destroy: (bool) false, DestroyDeposed: (bool) false, DestroyTainted: (bool) false, Meta: (map[string]interface {}) <nil> }) --- FAIL: TestSchemaMap_Diff (0.01s) --- FAIL: TestSchemaMap_Diff/79-NewComputed_should_always_propagate_with_CustomizeDiff (0.00s) schema_test.go:3289: expected: *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"foo":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)} got: <nil> FAIL FAIL github.com/hashicorp/terraform/helper/schema 0.825s ```
-
- 27 Nov, 2018 1 commit
-
-
Martin Atkins authored
This is no longer effective and should not be used in any new schema.
-
- 17 Oct, 2018 3 commits
-
-
James Bardin authored
Terraform now handles any actual "diffing" of resource, and the existing Diff functions are only used to shim the schema.Provider to the new methods. Since terraform is handling what used to be the Diff, the provider now should not modify the diff based on RequiresNew due to it interfering with the ignore_changes handling.
-
James Bardin authored
The helper resource tests won't pass for now, as they use a terraform.MockProvider which can't be used in the schema.Provider shims.
-
James Bardin authored
This exposes the internal schemaMap for use by the new provider shims.
-
- 16 Aug, 2018 1 commit
-
-
Paul Tyng authored
-
- 30 Mar, 2018 1 commit
-
-
Adam Lewandowski authored
-
- 14 Mar, 2018 2 commits
-
-
Guillaume J. Charmes authored
Signed-off-by:
Guillaume J. Charmes <gcharmes@magicleap.com>
-
James McGill authored
For historical reasons, the handling of element types for maps is inconsistent with other collection types. Here we begin a multi-step process to make it consistent, starting by supporting both the "consistent" form of using a schema.Schema and an existing erroneous form of using a schema.Type directly. In subsequent commits we will phase out the erroneous form and require the schema.Schema approach, the same as we do for TypeList and TypeSet.
-
- 01 Feb, 2018 1 commit
-
-
Radek Simko authored
-
- 26 Dec, 2017 1 commit
-
-
James Bardin authored
slight change to go fmt coming in 0.10
-
- 20 Dec, 2017 2 commits
-
-
James Bardin authored
This new codepath with the getDiff "customzed" return value, along with the associated test need to be removed as soon as we can support unset fields from the config, so we don't continue to carry this broken behavior forward any longer than needed.
-
Chris Marchesi authored
This extends the internal diffChange method so that ResourceDiff's implementation of it can report back whether or not the value came from a customized diff. This is an effort to work to preserve the pre-ResourceDiff behaviour that ignores the diff for computed keys when the old value was populated but the new value wasn't - this behaviour is actually being depended on by users that are using it to exploit using zero values in modules. This should allow both scenarios to co-exist by shifting the NewComputed exemption over to exempting values that come from diff customization.
-