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. 24 Jun, 2020 3 commits
  2. 05 Jun, 2020 3 commits
  3. 28 May, 2020 1 commit
  4. 27 May, 2020 4 commits
    • tf-release-bot's avatar
      Cleanup after v0.12.26 release · 7e0fe566
      tf-release-bot authored
      7e0fe566
    • tf-release-bot's avatar
      v0.12.26 · e139cf60
      tf-release-bot authored
      e139cf60
    • Martin Atkins's avatar
      Update CHANGELOG.md · 192d638b
      Martin Atkins authored
      192d638b
    • Paddy's avatar
      command: Unmanaged providers · 2e75ff71
      Paddy authored
      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.
      
      This is a backport of 5127f1ef,
      with some adjustments to be compatible with Terraform 0.12's older model
      of provider plugins.
      2e75ff71
  5. 19 May, 2020 8 commits
  6. 18 May, 2020 1 commit
  7. 13 May, 2020 4 commits
  8. 12 May, 2020 3 commits
  9. 07 May, 2020 4 commits
  10. 06 May, 2020 2 commits
    • Lee Trout's avatar
      Add support for force pushing with the remote backend · 469b9bcf
      Lee Trout authored
      Both differing serials and lineage protections should be bypassed
      with the -force flag (in addition to resources).
      
      Compared to other backends we aren’t just shipping over the state
      bytes in a simple payload during the persistence phase of the push
      command and the force flag added to the Go TFE client needs to be
      specified at that time.
      
      To prevent changing every method signature of PersistState of the
      remote client I added an optional interface that provides a hook
      to flag the Client as operating in a force push context. Changing
      the method signature would be more explicit at the cost of not
      being used anywhere else currently or the optional interface pattern
      could be applied to the state itself so it could be upgraded to
      support PersistState(force bool) only when needed.
      
      Prior to this only the resources of the state were checked for
      changes not the lineage or the serial. To bring this in line with
      documented behavior noted above those attributes a...
      469b9bcf
    • Lee Trout's avatar
      Add remote state test for serial and lineage changes · d475fd01
      Lee Trout authored
      We only persist a new state if the actual state contents have
      changed. This test demonstrates that behavior by calling write
      and persist methods when either the lineage or serial have changed.
      d475fd01
  11. 05 May, 2020 7 commits