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.
  1. 26 Jan, 2021 1 commit
  2. 02 Dec, 2020 1 commit
  3. 08 Aug, 2019 1 commit
  4. 06 Aug, 2019 1 commit
  5. 30 Jul, 2019 1 commit
  6. 29 Jul, 2019 1 commit
    • James Bardin's avatar
      don't reflect nil in schema validation · 016c4f78
      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.
      016c4f78
  7. 27 Jul, 2019 1 commit
    • James Bardin's avatar
      don't validate MinItems with unknowns in a block · 4bed030d
      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.
      4bed030d
  8. 18 Jul, 2019 1 commit
  9. 28 May, 2019 1 commit
  10. 14 May, 2019 1 commit
    • James Bardin's avatar
      remove SkipCoreTypeCheck · c8a2f384
      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.
      c8a2f384
  11. 11 May, 2019 1 commit
    • James Bardin's avatar
      validate integers when using protoV5 · 6bc36d33
      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.
      6bc36d33
  12. 17 Apr, 2019 2 commits
  13. 08 Apr, 2019 1 commit
  14. 29 Mar, 2019 1 commit
  15. 27 Mar, 2019 1 commit
  16. 21 Mar, 2019 1 commit
    • Martin Atkins's avatar
      helper/schema: Schema.SkipCoreTypeCheck flag · 7f860dc8
      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.
      7f860dc8
  17. 18 Mar, 2019 2 commits
  18. 14 Mar, 2019 1 commit
    • Martin Atkins's avatar
      helper/schema: Schema.AsSingle flag · 1c815042
      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.
      1c815042
  19. 12 Mar, 2019 1 commit
    • Martin Atkins's avatar
      helper/schema: ConfigMode field in *Schema · a6d322ed
      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.
      a6d322ed
  20. 08 Mar, 2019 1 commit
  21. 12 Feb, 2019 1 commit
  22. 05 Feb, 2019 2 commits
    • James Bardin's avatar
      add proto5 feature flag · 55b43077
      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.
      55b43077
    • James Bardin's avatar
      DiffSuppressFunc should noop diffs in sets · 81a4e705
      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.
      81a4e705
  23. 30 Jan, 2019 1 commit
  24. 04 Jan, 2019 1 commit
    • Martin Atkins's avatar
      helper/schema: Skip validation of unknown values · 06acc3f6
      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.
      06acc3f6
  25. 05 Dec, 2018 1 commit
    • Brian Flad's avatar
      helper/schema: Always propagate NewComputed for previously zero value primative type attributes · 1e81a3e7
      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
      ```
      1e81a3e7
  26. 27 Nov, 2018 1 commit
  27. 17 Oct, 2018 3 commits
    • James Bardin's avatar
      create a SimpleDiff for the new provider shims · 46b4c27d
      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.
      46b4c27d
    • James Bardin's avatar
      start work on helper/resource test fixtures · 0d4d572c
      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.
      0d4d572c
    • James Bardin's avatar
      add schema.InternalMap · bcc8be74
      James Bardin authored
      This exposes the internal schemaMap for use by the new provider shims.
      bcc8be74
  28. 16 Aug, 2018 1 commit
  29. 30 Mar, 2018 1 commit
  30. 14 Mar, 2018 2 commits
  31. 01 Feb, 2018 1 commit
  32. 26 Dec, 2017 1 commit
    • James Bardin's avatar
      go fmt · 4b49a323
      James Bardin authored
      slight change to go fmt coming in 0.10
      4b49a323
  33. 20 Dec, 2017 2 commits
    • James Bardin's avatar
      add FIXMEs · 0df8da59
      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.
      0df8da59
    • Chris Marchesi's avatar
      helper/schema: Extend diffChange and bubble up customized values · cb5ce1d3
      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.
      cb5ce1d3