12 Commits (dependabot/github_actions/github-actions-backward-compatible-d013ecdca1)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Bruno Schaatsbergen	a5d8673a41	Revert "Merge pull request #35929 from bschaatsbergen/b/fix-retry-messages-in-cloud-backend-json" ... This reverts commit f8cb25a246, reversing changes made to a25831d6ef.	1 year ago
Bruno Schaatsbergen	f1428b3388	backend/cloud: expose View to enable reuse in a (cloud) backend ... Signed-off-by: Bruno Schaatsbergen <git@bschaatsbergen.com>	1 year ago
Bruno Schaatsbergen	d8bfe7a80b	cloud: Initialize a new cloud view in the backend to render messages based on view type. ... Signed-off-by: Bruno Schaatsbergen <git@bschaatsbergen.com>	1 year ago
Bruno Schaatsbergen	f9797595e3	chore: initialize new view in meta backend ... Signed-off-by: Bruno Schaatsbergen <git@bschaatsbergen.com>	1 year ago
Martin Atkins	88cb4aeea3	backendrun: Separate the types/etc for backends that support operations ... We previously had all of the types and helpers for all kinds of backends together in package backend. That kept things relatively simple, but it also meant that the majority of backends that only deal with remote state storage ended up still indirectly depending on the entire Terraform modules runtime, configuration loader, etc, etc, which brings into scope a bunch of external dependencies that the remote state backends don't really need. Since backends that support operations are a rare exception, we'll move the types and helpers for those into a separate package "backendrun", and then the main package backend can have a much more modest set of types and, more importantly, a modest set of dependencies on other packages in this codebase. This is part of an ongoing effort to reduce the exposure of Terraform Core and CLI code to the remote backends and vice-versa, so that in the long run we can more often treat them as separate for dependency maintenance purposes.	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
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	5 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.	5 years ago