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...
      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 also have a “read”
      counterpart just like state has. These are now checked along with
      state to determine if the state as a whole is unchanged.
      
      Tests were altered to table driven test format and testing was
      expanded to include WriteStateForMigration and its interaction
      with a ClientForcePusher type.
      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