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.
- 01 Nov, 2021 3 commits
-
-
xiaozhu36 authored
-
Chris Arcand authored
command: Adjust skipping of resource counts for any remote implementation
-
James Bardin authored
Flatten `assume_role` block for OSS backend
-
- 30 Oct, 2021 1 commit
-
-
Chris Arcand authored
When using the Terraform Cloud integration - like the 'remote' backend - resource count output should be suppressed if those counts are being rendered remotely. This generalizes this to the shared BackendWithRemoteTerraformVersion interface.
-
- 29 Oct, 2021 36 commits
-
-
hc-github-team-tf-core authored
-
hc-github-team-tf-core authored
-
James Bardin authored
remove Crash section of issue template
-
James Bardin authored
Terraform is no longer going to silently capture all logs for a possible crash report, and therefor won't create a crash.log file when a panic is encountered. The prompt to create a log file with TF_LOG from the Debug Output section should suffice to get users to submit the logs when possible. In the case of a crash specifically, the crash output also requests that the stack trace be added to the issue for users who may not be aware of what is necessary.
-
James Bardin authored
Remove the use of panicwrap in the Terraform CLI
-
Chris Arcand authored
-
Martin Atkins authored
A more native integration for Terraform Cloud and its CLI-driven run workflow. Instead of a backend, users declare a special block in the top-level terraform settings block to configure Terraform Cloud, then run terraform init. Full documentation will follow in later commits.
-
Chris Arcand authored
-
Chris Arcand authored
-
Chris Arcand authored
The previous version is a little overdramatic and somewhat accusatory. Just lay it out how it is: TFC needs workspaces to be named.
-
Brandon Croft authored
This can help differentiate cloud integration API requests from normal remote backend requests
-
Chris Arcand authored
When the 'select the exact version if possible' behavior was added, the version check below it was never updated to take the newly updated version in to account, resulting in a failed version check even as the remote workspace updated to the correct version necessary.
-
Chris Arcand authored
-
Chris Arcand authored
-
Chris Arcand authored
E2E tests including cost estimation should indeed be added, but the default case should be disabled; lots of cycles lost to pointless cost estimates on null and random resources.
-
Omar Ismail authored
-
Barrett Clark authored
-
Chris Arcand authored
This aligns more with the existing copy for backends
-
Nick Fagerlund authored
The delete + assign at the end of `Update` and `UpdateByID` are meant to handle renaming a workspace — (remove old name), (insert new name). However, `UpdateByID` was doing (remove new name), (insert new name) and leaving the old name in place. This commit changes it to match `Update` by grabbing the original name off the workspace object _before_ potentially renaming it.
-
Chris Arcand authored
-
Nick Fagerlund authored
Alas, there's not a very good way to test the message we're supposed to print to the console in this situation; we just don't appear to have a mock terminal that the test can read from. But we can at least test that the function returns without erroring under the exact conditions where it was erroring before. Note that the behaviors of mc.Workspaces.Update and UpdateByID were already starting to drift, so I consolidated their actual attribute update logic into a helper function before they drifted much further.
-
Nick Fagerlund authored
Previously, if the remote TFC/TFE instance doesn't happen to have a tool_version record whose name exactly matches the value of `tfversion.String()`, Terraform would be completely blocked from using the `terraform workspace new` command (when configured with the tags strategy) — the API would give a 422 to the whole create request. This commit changes the StateMgr() function to do the work in two passes; first create the workspace (which should work fine regardless), THEN update the Terraform version and print a warning to the terminal if it fails (which 99% of the time is a benign failure with little impact on your future CLI usage).
-
Chris Arcand authored
-
Brandon Croft authored
-
Omar Ismail authored
-
Barrett Clark authored
If you move from the remote backend to the cloud block you will see this error message.
-
Chris Arcand authored
-
Chris Arcand authored
-
Barrett Clark authored
-
Barrett Clark authored
There are actually a few different ways to get to this message. 1. Blank state — no previous terraform applied. Start with a cloud block. 1. Implicit local — start with no backend specified. This actually goes through the same code execution path as the first scenario. 1. Explicit local — start with a backend local block that has been applied, then change from the local backend to a cloud block. This will recognize the state, and is a different path through the code in the meta backend. This commit handles the last case. The messaging has also been tweaked. End to end test included as well.
-
-
Barrett Clark authored
-
Omar Ismail authored
-
Omar Ismail authored
-
Chris Arcand authored
-
Omar Ismail authored
* Add test for tfc to tfc mgiration * Fix old tests, and remove unused code.
-