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. 19 May, 2022 8 commits
  2. 18 May, 2022 24 commits
  3. 11 May, 2022 5 commits
    • hc-github-team-tf-core's avatar
      85543e8d
    • hc-github-team-tf-core's avatar
      Release v1.2.0-rc2 · be7d9014
      hc-github-team-tf-core authored
      be7d9014
    • Martin Atkins's avatar
      Update CHANGELOG.md · c21e3436
      Martin Atkins authored
      c21e3436
    • Martin Atkins's avatar
      core: Defer on transitive dependencies for data resources with conditions · 8758f238
      Martin Atkins authored
      When a data resource is used for the purposes of verifying a condition
      about an object managed elsewhere (e.g. if the managed resource doesn't
      directly export all of the information required for the condition) it's
      important that we defer the data resource read to the apply step if the
      corresponding managed resource has any changes pending.
      
      Typically we'd expect that to come "for free" but unfortunately we have
      a pragmatic special case in our handling of data resources where we
      normally defer to the apply step only if a _direct_ dependency of the data
      resource has a change pending, and allow a plan-time read if there's
      a pending change in an indirect dependency. This allowed us to preserve
      some compatibility with the questionable historical behavior of always
      reading data resources proactively unless the configuration contains
      unknown values, since the arguably-more-correct behavior would've been a
      regression for anyone who had been depending on that before.
      
      Since preconditions and postconditions didn't exist until now, we are not
      constrained in the same way by backward compatibility, and so we can adopt
      the more correct behavior in the case where a data resource has conditions
      specified. This does unfortunately make the handling of data resources
      with conditions subtly inconsistent with those that don't, but this is
      a better situation than the alternative where it would be easy to get into
      a trapped situation where the remote system is invalid and it's impossible
      to plan the change that would make it valid again because the conditions
      evaluate too soon, prior to the fix being applied.
      8758f238
    • Martin Atkins's avatar
      core: Report reason for deferring data read until apply · 3fc61239
      Martin Atkins authored
      We have two different reasons why a data resource might be read only
      during apply, rather than during planning as usual: the configuration
      contains unknown values, or the data resource as a whole depends on a
      managed resource which itself has a change pending.
      
      However, we didn't previously distinguish these two in a way that allowed
      the UI to describe the difference, and so we confusingly reported both
      as "config refers to values not yet known", which in turn led to a number
      of reasonable questions about why Terraform was claiming that but then
      immediately below showing the configuration entirely known.
      
      Now we'll use our existing "ActionReason" mechanism to tell the UI layer
      which of the two reasons applies to a particular data resource instance.
      The "dependency pending" situation tends to happen in conjunction with
      "config unknown", so we'll prefer to refer that the configuration is
      unknown if both are true.
      3fc61239
  4. 05 May, 2022 3 commits