5 Commits (7bee77bdd3dc67de0973e1c19bd5a1685dc805c0)

Author	SHA1	Message	Date
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Sebastian Rivera	de574ae6d4	Initial implementation of structured logging in cloud backend (#32504) ... * Implementation of structured logging. These are the changes that enable the cloud backend to consume structured logs and make use of the new plan renderer. This will enable CLI-driven runs to view the structured output in the Terraform Cloud UI. * Cloud structured logging unit tests * Remove deferred logs logic, fix minor issues Color formatting fixes, log type stop lists, default behavior for logs that are unknown * Use service disco path in redacted plan url	3 years ago
Sebastian Rivera	9d7fdbea2d	Handle -input=false in cloud integration ... 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.	4 years ago
Chris Arcand	50997d9a32	Restore API version checking, with internal usage accounted for	4 years ago
Chris Arcand	ea8ad0b15a	Initial commit of 'cloud' package ... 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.	4 years ago