41 Commits (94de72c63834acea811c27a585c19eae29374a4b)

Author	SHA1	Message	Date
Anna Winkler	22c121df86	Bump compatibility version to 1.3.0 for terraform core release (#30988) ... * Bump compatibility version to 1.3.0 for terraform core release Co-authored-by: Brandon Croft <brandon.croft@gmail.com>	4 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
Sebastian Rivera	5ded48e081	Give token in cloud config higher precedence than CLI config file	4 years ago
Sebastian Rivera	f63ef2b5ef	Rename cloud env vars to use TF_CLOUD prefix	4 years ago
Brandon Croft	a38a0ee8a8	test(cloud): ensure mocks are used for backend configure tests ... Also adds a few new tests for cloud configuration using environment variables	4 years ago
Sebastian Rivera	dd864b1bac	Add TF_WORKSPACE validation method	4 years ago
Sebastian Rivera	995ef15ab9	Add cloud configuration support for TF_WORKSPACE ... TF_WORKSPACE can now be used for your cloud configuration, effectively serving as an alternative to setting the name attribute in your workspaces configuration.	4 years ago
Sebastian Rivera	232d48fe00	Add support for TF_HOSTNAME env var	4 years ago
Sebastian Rivera	b1c22d333e	Fix error formatting for missing env and config value ... We previously used to throw an error denoting where in the configuration the attribute was missing or invalid. Considering that organization can be now be omitted from the configuration, our previous error message will be improperly formatted. This commit also updates the message to mention `TF_ORGANIZATION` as a valid substitute if organization is missing or invalid in the configuration.	4 years ago
Sebastian Rivera	45357f5004	Add TF_ORGANIZATION env var support ... TF_ORGANIZATION will serve as a fallback for configuring the organization in the `cloud` block. This is the first step to make it easier for users wanting to configure Terraform programmatically.	4 years ago
Luces Huayhuaca	bdc7d8c0a1	Upgrade go-tfe dependency to use 1.0 version. It contains breaking changes, so we are updating method signatures, method names and the type of optional parameters, as needed. (#30626)	4 years ago
Theo Chupp	d15a2bc024	fix: local variables should not be overridden by remote variables during `terraform import` (#29972) ... * fix: local variables should not be overridden by remote variables during `terraform import` * chore: applied the same fix in the 'internal/cloud' package * backport changes from cloud package to remote package Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com> Co-authored-by: uturunku1 <luces.huayhuaca@gmail.com>	4 years ago
Chris Arcand	21750037d5	cloud: Help output typos	4 years ago
Luces Huayhuaca	4e3218b4d5	cloud: convert uses of worspaces.operations into workspaces.executionMode (#29844) ... * convert uses of worspaces.operations into workspaces.executionMode The cloud package currently uses a deprecated API on workspaces to determine a workspace's execution mode. Deprecated: Operations (boolean) New hotness: Execution mode (string - "local", "remote", or "agent") More details: https://www.terraform.io/docs/cloud/api/workspaces.html#request-body All uses of Operations field coming from the client (within the cloud package) should be converted to the appropriate ExecutionMode equivalent. Also, we need to update all acknowledgment of operations field on the tests that are testing the behavior of workspaces. Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com> Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>	4 years ago
Omar Ismail	1da7031855	cloud: Add tags to workspace if necessary when fetching state	5 years ago
Alisdair McDiarmid	a61bd8a96b	cloud: Fix prerelease version constraint checks	5 years ago
Brandon Croft	6d9c919f55	adds X-Terraform-Integration header ... This can help differentiate cloud integration API requests from normal remote backend requests	5 years ago
Chris Arcand	3d23a8e062	cloud: Fix version check regression ... 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.	5 years ago
Omar Ismail	fc5863844c	Cloud migration: ignore backend version check when empty worksapces	5 years ago
Chris Arcand	50997d9a32	Restore API version checking, with internal usage accounted for	5 years ago
Nick Fagerlund	c99f5972de	cloud.StateMgr(): Set terraform version AFTER creating workspace ... 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).	5 years ago
Chris Arcand	12a4af3e72	Temporarily skip API version checking	5 years ago
Nick Fagerlund	baa72ce235	Simplify logic flow: everything is a constraint ... Explicit version strings are actually also version constraints! And the special comparisons we were doing to allow a range of compatible versions can also be expressed as version constraints. Bonus: also simplify the way we handle version check errors, by composing the messages inline and only extracting the repetitive parts into a function.	5 years ago
Barrett Clark	83538fdd6b	Shift errors to error file, improve error text	5 years ago
Nick Fagerlund	b43daeaa8d	Cloud backend: accept version constraints from workspaces ... The cloud backend (and remote before it) previously expected a TFC workspace's `terraform-version` attribute to be either the magic string `"latest"` or an explicit semver value. But a workspace might have a version constraint instead (like `~> 1.1.0`), in which case the version check would blow up. This commit checks whether `terraform-version` is a valid version constraint before erroring out, and if so, returns success if the local version meets the constraint. Because it's not practical to deeply introspect the slice of version space defined by a constraint, this check is slightly less robust than the version comparisons below it: - It can give a false OK on open-ended constraints like `>= 1.1.0`. Say you're running 1.3.0, it changed the state format, and the TFE instance admin has not yet added any 1.3.x Terraform versions; your workspace will now break. - It will give a false not-OK when using different minor versions within a range that we know to be compatible, e.g. remote constraint of `~> 0.15.0` and local version of 1.1.0. - This would be totally useless with the pre-0.14 versions of Terraform, where patch releases could change state format... but we're not going back in time to add this feature to them anyway. Still, in the most common likely case (`~> x.y.z`), it'll complain at you (with an error you can choose to override) if you're not using the same minor version, and that seems proportionate, useful, and expected.	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
Barrett Clark	edbc84420c	Run apply -refresh-state instead of refresh ... When a user runs `terraform refresh` we give them an error message that tells them to run `terraform apply -refresh-state`. We could just run that command for them, though. That is what this PR does.	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	46e47ed379	Use the 'tfe' service for everything. ... The 'tfe' service was appended to with various versions to denote a new 'feature' implemented by a new 'service'. This quickly proved to not be scalable, as adding an entry to the discovery document from every feature is bad. The new mechanism added was checking the TFP-API-Version header on requests for a version, instead. So we'll remove the separation here between different tfe service 'versions' and the separate 'state' service and Just Use TFE, as well as the TFP-API-Version header for all feature versioning., as well as the TFP-API-Version header for all feature versioning.	5 years ago
Chris Arcand	412679522d	Remove all constraint checking ... This is an outdated mechanism that isn't used anymore.	5 years ago
Chris Arcand	ee384e8716	Attempt to set current Terraform version on new workspaces, always	5 years ago
Chris Arcand	aba7d96596	cloud: Support interop from 0.14 to 1.1 ... The previous conservative guarantee that we would not make backwards incompatible changes to the state file format until at least Terraform 1.1 can now be extended. Terraform 0.14 through 1.1 will be able to interoperably use state files, so we can update the remote backend version compatibility check accordingly. This is a port of https://github.com/hashicorp/terraform/pull/29645	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	a94b2405b1	static checker	5 years ago
Chris Arcand	6dcd0db265	Map CLI workspaces by TFC tags	5 years ago
Chris Arcand	7a243379fb	cloud: Refactor workspaceMapping concerns into strategy()	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
Omar Ismail	0a125c0400	Cloud: refactor setting attributes, add tests	5 years ago
Omar Ismail	8f49757f89	Add testing for Cloud PrepareConfig	5 years ago
Martin Atkins	f4758803fe	cloud: Backend implements new version of the backend.Local interface ... This makes the new backend compatible with the new terraform.Context API, which has changed in main.	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