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 Apr, 2022 1 commit
-
-
Sebastian Rivera authored
For non-interactive contexts, Terraform is typically executed with the flag -input=false. However for runs that are not set to auto approve, the cloud integration will prompt a user for approval input even with input being set to false. This commit enables the cloud integration to know the value of the input flag and use it to determine whether or not to ask the user for input. If -input is set to false and the run cannot be auto approved, the cloud integration will throw an error stating run confirmation can no longer be handled in the CLI and that they must do so through the browser.
-
- 29 Oct, 2021 6 commits
-
-
Omar Ismail authored
Run variables allow the run API to accept input variables not found in the configuration slug (the file-based ones plus workspace vars)
-
Chris Arcand authored
These changes remove all of the preexisting version checking for individual features, wiping the slate clean with an overall minimum requirement of a future TFP-API-Version 2.5, which at the time of this writing is expected to be TFE v202112-1. It also actually provides that expected TFE version as an actionable error message, rather than generically saying that it isn't supported or using the somewhat opaque API version header.
-
Omar Ismail authored
-
Omar Ismail authored
-
Chris Arcand authored
-
Chris Arcand authored
The cloud package intends to implement a new integration for Terraform Cloud/Enterprise. The purpose of this integration is to better support TFC users; it will shed some overly generic UX and architecture, behavior changes that are otherwise backwards incompatible in the remote backend, and technical debt - all of which are vestiges from before Terraform Cloud existed. This initial commit is largely a porting of the existing 'remote' backend, which will serve as an underlying implementation detail and not be a typical user-level backend. This is because to re-implement the literal backend interface is orthogonal to the purpose of this integration, and can always be migrated away from later. As this backend is considered an implementation detail, it will not be registered as a declarable backend. Within these changes it is, for easy of initial development and a clean diff.
-
- 14 Sep, 2021 1 commit
-
-
Martin Atkins authored
The presence of this field was confusing because in practice the local backend doesn't use it for anything and the remote backend was using it only to return an error if it's set to anything other than the default, under the assumption that it would always match ContextOpts.Parallelism. The "command" package is the one actually responsible for handling this option, and it does so by placing it into the partial ContextOpts which it passes into the backend when preparing for a local operation. To make that clearer, here we remove Operation.Parallelism and change the few uses of it to refer to ContextOpts.Parallelism instead, so that everyone is reading and writing this value from the same place.
-
- 18 May, 2021 1 commit
-
-
CJ Horton authored
-
- 17 May, 2021 5 commits
-
-
Chris Arcand authored
-
Martin Atkins authored
This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
-
Martin Atkins authored
This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
-
Martin Atkins authored
This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
-
Martin Atkins authored
This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
-
- 27 Apr, 2021 1 commit
-
-
Martin Atkins authored
So far we've only had "normal mode" and "destroy mode", where the latter is activated either by "terraform plan -destroy" or "terraform destroy". In preparation for introducing a third mode "refresh only" this generalizes how we handle modes so we can potentially deal with an arbitrary number of modes, although for now we only intend to have three. Mostly this is just a different implementation of the same old behavior, but there is one small user-visible difference here: the "terraform apply" command now accepts a -destroy option, mirroring the option of the same name on "terraform plan", which in turn makes "terraform destroy" effectively a shorthand for "terraform apply -destroy". This is intended to make us consistent that "terraform apply" without a plan file argument accepts all of the same plan-customization options that "terraform plan" does, which will in turn avoid us having to add a new alias of "terraform plan" for each new plan mode we might add. The -help output is changed in that vein here, although we'll wait for subsequent commit to make a similar change to the website documentation just so we can deal with the "refresh only mode" docs at the same time.
-
- 03 Feb, 2021 1 commit
-
-
Alisdair McDiarmid authored
This dramatically simplifies the logic around auto-approve, which is nice. Also add test coverage for the manual approve step, for both apply and destroy, answering both yes and no.
-
- 15 May, 2020 2 commits
-
-
CJ Horton authored
-
Martin Atkins authored
Previously we did not allow -target to be used with the remote backend because there was no way to send the targets to Terraform Cloud/Enterprise via the API. There is now an attribute in the request for creating a plan that allows us to send target addresses, so we'll remove that restriction and copy the given target addresses into the API request.
-
- 18 Oct, 2019 1 commit
-
-
Martin Atkins authored
The remote backend uses backend.ParseVariableValues locally only to decide if the user seems to be trying to use -var or -var-file options locally, since those are not supported for the remote backend. Other than detecting those, we don't actually have any need to use the results of backend.ParseVariableValues, and so it's better for us to ignore any errors it produces itself and prefer to just send a potentially-invalid request to the remote system and let the remote system be responsible for validating it. This then avoids issues caused by the fact that when remote operations are in use the local system does not have all of the required context: it can't see which environment variables will be set in the remote execution context nor which variables the remote system will set using its own generated -var-file based on the workspace stored variables.
-
- 14 Jun, 2019 1 commit
-
-
Mary Cutrali authored
-
- 08 Mar, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 25 Feb, 2019 1 commit
-
-
Sander van Harmelen authored
Previously we checked can-update in order to determine if a user had the required permissions to apply a run, but that wasn't sufficient. So we added a new permission, can-queue-apply, that we now use instead.
-
- 07 Feb, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 08 Jan, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 20 Nov, 2018 1 commit
-
-
Sander van Harmelen authored
In order to support free organizations, we need a way to load the `remote` backend and then, depending on the used offering/plan, enable or disable remote operations. In other words, we should be able to dynamically fall back to the `local` backend if needed, after first configuring the `remote` backend. To make this works we need to change the way this was done previously when the env var `TF_FORCE_LOCAL_BACKEND` was set. The clear difference of course being that the env var would be available on startup, while the used offering/plan is only known after being able to connect to TFE.
-
- 06 Nov, 2018 1 commit
-
-
Sander van Harmelen authored
This is a refactored version of the `remote` backend that was initially added to Terraform v0.11.8 which should now be compatible with v0.12.0.
-
- 17 Oct, 2018 1 commit
-
-
Martin Atkins authored
This work was done against APIs that were already changed in the branch before work began, and so it doesn't apply to the v0.12 development work. To allow v0.12 to merge down to master, we'll revert this work out for now and then re-introduce equivalent functionality in later commits that works against the new APIs.
-
- 16 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
-
- 15 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
-
- 11 Oct, 2018 2 commits
-
-
Sander van Harmelen authored
-
Sander van Harmelen authored
-
- 09 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
We previously asked to override a soft-failed policy, even wehn -auto-approve was set. That is now fixed by returning a policy failed error.
-
- 08 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
This commit adds logic to check if a workspace is configured to auto apply changes. And if it does, we make sure we output all steps correctly.
-
- 05 Oct, 2018 2 commits
-
-
Sander van Harmelen authored
For Plan only: -module-depth=n For Plan & Apply -parallelism=m -refresh=false -var “foo=bar” and -var-file=foo
-
Sander van Harmelen authored
-
- 04 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
This reverts commit f09c2db8, reversing changes made to 8394dc79.
-
- 02 Oct, 2018 1 commit
-
-
Sander van Harmelen authored
If the policy passes, only show that instead of the full check output to prevent cluttering the output. So a passing policy will only show: ----------------------------------------------- Organization policy check: passed -----------------------------------------------
-
- 26 Sep, 2018 1 commit
-
-
Sander van Harmelen authored
-
- 22 Sep, 2018 2 commits
-
-
Sander van Harmelen authored
This commit adds: - support for `-lock-timeout` - custom error message when a 404 is received - canceling a pending run when TF is Ctrl-C’ed - discard a run when the apply is not approved
-
Sander van Harmelen authored
-