12 Commits (6dcf00aefc56b48bae54822a6e62eacffd2bc3ea)

Author	SHA1	Message	Date
Brandon Croft	1f01ba4dbc	fix(run variables): support all variable types (map, list, bool, number, null, string) ... All run variables remain encoded as strings in the API but will now be expressed as an HCL value to be evaluated correctly by the remote terraform. Previously, only strings were supported. Examples: string: `"quoted literal"` (strings must be quoted) map: `{ foo = "bar" }` list: `["foo", "bar"]` bool: `true` null: `null` number: `0.0001` This requires the API to anticipate that all run variables will be HCL values	5 years ago
Barrett Clark	83337de654	Remove prefix from the cloud backend config ... Now that we have tags we no longer need prefix.	5 years ago
Omar Ismail	dd856f8a1b	Add run variables to cloud plan operations from non-file sources ... Run variables allow the run API to accept input variables not found in the configuration slug (the file-based ones plus workspace vars)	5 years ago
Chris Arcand	7cc53fe163	cloud: Set minimum TFE version ... 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.	5 years ago
Chris Arcand	a4e196d067	Port backend/local: Check dependency lock consistency before any operations ... This is a port of the changes made in #29683	5 years ago
Chris Arcand	74e087dc29	Rename cloud.testBackendDefault -> cloud.testBackendWithName	5 years ago
Chris Arcand	d2b6b5f2b3	cloud: Align local and remote workspace name with 'name' strategy ... This changes the 'name' strategy to always align the local configured workspace name and the remote Terraform Cloud workspace, rather than the implicit use of the 'default' unnamed workspace being used instead. What this essentially means is that the Cloud integration does not fully support workspaces when configured for a single TFC workspace (as was the case with the 'remote' backend), but *does* use the backend.Workspaces() interface to allow for normal local behaviors like terraform.workspace to resolve to the correct name. It does this by always setting the local workspace name when the 'name' strategy is used, as a part of initialization. Part of the diff here is exporting all the previously unexported types for mapping workspaces. The command package (and init in particular) needs to be able to handle setting the local workspace in this particular scenario.	5 years ago
Omar Ismail	594a390f84	Use context parallelism	5 years ago
Chris Arcand	9bdf1d2579	Rename testBackendNoDefault ... "NoDefault" is now ambiguous with tags, and it does not imply using a prefix.	5 years ago
Chris Arcand	922a8e4488	Refactor private workspace fields into workspaceMapping ... A mostly cosemetic change; The fields 'workspace' and 'prefix' don't really describe well what they are from a caller, so change these to use a workspaceMapping struct to convey they are for implementing workspace mapping strategies from CLI -> TFC	5 years ago
Chris Arcand	471dd479e8	Update go-tfe to 26689e ... These changes include additions to fulfill the interface for the client mock, plus moving all that logic (which needn't be duplicated across both the remote and cloud packages) over to the cloud package under a dedicated mock client file.	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