33 Commits (f-debugger)

Author	SHA1	Message	Date
Omar Ismail	e9c7f37b8c	Enable --auto-approve for Policy checks on Remote Backend (Terraform Cloud) (#27804) ... * Fix auto-approve for soft-policy * Update error handling * update testing string for consistency	5 years ago
Alisdair McDiarmid	7c0ec0107f	backend: Replace ShowDiagnostics with view.Diagnostics	5 years ago
Alisdair McDiarmid	68558ccd54	backend/local: Replace CLI with view instance ... This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.	5 years ago
Alisdair McDiarmid	2d1976bbda	clistate: Update clistate.Locker for command views ... The clistate package includes a Locker interface which provides a simple way for the local backend to lock and unlock state, while providing feedback to the user if there is a delay while waiting for the lock. Prior to this commit, the backend was responsible for initializing the Locker, passing through direct access to the cli.Ui instance. This structure prevented commands from implementing different implementations of the state locker UI. In this commit, we: - Move the responsibility of creating the appropriate Locker to the source of the Operation; - Add the ability to set the context for a Locker via a WithContext method; - Replace the Locker's cli.Ui and Colorize members with a StateLocker view; - Implement views.StateLocker for human-readable UI; - Update the Locker interface to return detailed diagnostics instead of errors, reducing its direct interactions with UI; - Add a Timeout() method on Locker to allow the remote backend to continue to misuse the -lock-timeout flag to cancel pending runs. When an Operation is created, the StateLocker field must now be populated with an implementation of Locker. For situations where locking is disabled, this can be a no-op locker. This change has no significant effect on the operation of Terraform, with the exception of slightly different formatting of errors when state locking or unlocking fails.	5 years ago
Alisdair McDiarmid	536c80da23	backend: Add per-operation diagnostic rendering ... The enhanced backends (local and remote) need to be able to render diagnostics during operations. Prior to this commit, this functionality was supported with a per-backend `ShowDiagnostics` function pointer. In order to allow users of these backends to control how diagnostics are rendered, this commit moves that function pointer to the `Operation` type. This means that a diagnostic renderer is configured for each operation, rather than once per backend initialization. Some secondary consequences of this change: - The `ReportResult` method on the backend is now moved to the `Operation` type, as it needs to access the `ShowDiagnostics` callback (and nothing else from the backend); - Tests which assumed that diagnostics would be written to the backend's `cli.Ui` instance are migrated to using a new record/playback diags helper function; - Apply, plan, and refresh commands now pass a pointer to the `Meta` struct's `showDiagnostics` method. This commit should not change how Terraform works, and is refactoring in preparation for more changes which move UI code out of the backend.	5 years ago
Alisdair McDiarmid	5ca118b4e6	cli: Move resource count code to command package ... CountHook is an implementation of terraform.Hook which is used to calculate how many resources were added, changed, or destroyed during an apply. This hook was previously injected in the local backend code, which means that the apply command code has no access to these counts. This commit moves the CountHook code into the command package, and removes an unused instance of the hook in the plan code path. The goal here is moving UI code into the command package.	5 years ago
Alisdair McDiarmid	619c6727ef	backend/remote: No version check for operations ... Terraform remote version conflicts are not a concern for operations. We are in one of three states: - Running remotely, in which case the local version is irrelevant; - Workspace configured for local operations, in which case the remote version is meaningless; - Forcing local operations with a remote backend, which should only happen in the Terraform Cloud worker, in which case the Terraform versions by definition match. This commit therefore disables the version check for operations (plan and apply), which has the consequence of disabling it in Terraform Cloud and Enterprise runs. In turn this enables Terraform Enterprise runs with bundles which have a version that doesn't exactly match the bundled Terraform version.	5 years ago
Alisdair McDiarmid	c5c1f31db3	backend: Validate remote backend Terraform version ... When using the enhanced remote backend, a subset of all Terraform operations are supported. Of these, only plan and apply can be executed on the remote infrastructure (e.g. Terraform Cloud). Other operations run locally and use the remote backend for state storage. This causes problems when the local version of Terraform does not match the configured version from the remote workspace. If the two versions are incompatible, an `import` or `state mv` operation can cause the remote workspace to be unusable until a manual fix is applied. To prevent this from happening accidentally, this commit introduces a check that the local Terraform version and the configured remote workspace Terraform version are compatible. This check is skipped for commands which do not write state, and can also be disabled by the use of a new command-line flag, `-ignore-remote-version`. Terraform version compatibility is defined as: - For all releases before 0.14.0, local must exactly equal remote, as two different versions cannot share state; - 0.14.0 to 1.0.x are compatible, as we will not change the state version number until at least Terraform 1.1.0; - Versions after 1.1.0 must have the same major and minor versions, as we will not change the state version number in a patch release. If the two versions are incompatible, a diagnostic is displayed, advising that the error can be suppressed with `-ignore-remote-version`. When this flag is used, the diagnostic is still displayed, but as a warning instead of an error. Commands which will not write state can assert this fact by calling the helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the checks. Those which can write state should instead call the helper `meta.remoteBackendVersionCheck`, which will return diagnostics for display. In addition to these explicit paths for managing the version check, we have an implicit check in the remote backend's state manager initialization method. Both of the above helpers will disable this check. This fallback is in place to ensure that future code paths which access state cannot accidentally skip the remote version check.	6 years ago
Alisdair McDiarmid	eee57280f6	backend: Faster remote backend tests ... The remote backend tests spent most of their execution time sleeping in various polling and backoff waits. This is unnecessary when testing against a mock server, so reduce all of these delays when under test to much lower values. Only one remaining test has an artificial delay: verifying the discovery of services against an unknown hostname. This times out at DNS resolution, which is more difficult to fix than seems worth it at this time.	6 years ago
Kristin Laemmert	86e9ba3d65	* backend/local: push responsibility for unlocking state into individual operations ... * unlock the state if Context() has an error, exactly as backend/remote does today * terraform console and terraform import will exit before unlocking state in case of error in Context() * responsibility for unlocking state in the local backend is pushed down the stack, out of backend.go and into each individual state operation * add tests confirming that state is not locked after apply and plan * backend/local: add checks that the state is unlocked after operations This adds tests to plan, apply and refresh which validate that the state is unlocked after all operations, regardless of exit status. I've also added specific tests that force Context() to fail during each operation to verify that locking behavior specifically.	6 years ago
CJ Horton	e1dcae17b7	add sad path tests for the TFP API version check	6 years ago
Martin Atkins	16f1f3b739	backend/remote: Support -target on plan and apply ... Previously we did not allow -target to be used with the remote backend because there was no way to send the targets to Terraform Cloud/Enterprise via the API. There is now an attribute in the request for creating a plan that allows us to send target addresses, so we'll remove that restriction and copy the given target addresses into the API request.	6 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Sander van Harmelen	9f6a126293	backend/remote: check for external updates	7 years ago
Sander van Harmelen	01f17fa0ca	backend/remote: exit with 1 when a run is canceled	7 years ago
Sander van Harmelen	47a00ea34b	backend/remote: cleanup test connections ... Cleanup test connection to prevent file descriptor issues when running the tests on a Mac.	7 years ago
Martin Atkins	0c0a437bcb	Move module install functionality over to internal/initwd	7 years ago
Sander van Harmelen	4561c80c1d	Also show policies when there are no changes ... This behavior was recently updated in the TFE UI, so lets follow that behavior here as well.	8 years ago
Sander van Harmelen	a17f317025	Change how to fall back from remote to local backend ... In order to support free organizations, we need a way to load the `remote` backend and then, depending on the used offering/plan, enable or disable remote operations. In other words, we should be able to dynamically fall back to the `local` backend if needed, after first configuring the `remote` backend. To make this works we need to change the way this was done previously when the env var `TF_FORCE_LOCAL_BACKEND` was set. The clear difference of course being that the env var would be available on startup, while the used offering/plan is only known after being able to connect to TFE.	8 years ago
Sander van Harmelen	52a1b22f7a	Implement the remote enhanced backend ... This is a refactored version of the `remote` backend that was initially added to Terraform v0.11.8 which should now be compatible with v0.12.0.	8 years ago
Martin Atkins	541952bb8f	Revert some work that happened since v0.12-dev branched ... This work was done against APIs that were already changed in the branch before work began, and so it doesn't apply to the v0.12 development work. To allow v0.12 to merge down to master, we'll revert this work out for now and then re-introduce equivalent functionality in later commits that works against the new APIs.	8 years ago
Sander van Harmelen	d78470ad5a	Don’t ask questions when -auto-approve is set ... We previously asked to override a soft-failed policy, even wehn -auto-approve was set. That is now fixed by returning a policy failed error.	8 years ago
Sander van Harmelen	53a8aaaf85	Merge pull request #19022 from hashicorp/f-auto-apply ... backend/remote: properly handle workspaces that auto apply changes	8 years ago
Sander van Harmelen	194863db4e	Properly handle workspaces that auto apply changes ... This commit adds logic to check if a workspace is configured to auto apply changes. And if it does, we make sure we output all steps correctly.	8 years ago
Sander van Harmelen	b1fdbd7db8	Allow enhanced backends to pass custom exit codes ... In some cases this is needed to keep the UX clean and to make sure any remote exit codes are passed through to the local process. The most obvious example for this is when using the "remote" backend. This backend runs Terraform remotely and stream the output back to the local terminal. When an error occurs during the remote execution, all the needed error information will already be in the streamed output. So if we then return an error ourselves, users will get the same errors twice. By allowing the backend to specify the correct exit code, the UX remains the same while preserving the correct exit codes.	8 years ago
Sander van Harmelen	67db9da000	Add checks for all flags we currently don’t support ... For Plan only: -module-depth=n For Plan & Apply -parallelism=m -refresh=false -var “foo=bar” and -var-file=foo	8 years ago
Sander van Harmelen	ffc67a8e90	Prevent running plan or apply without permissions	8 years ago
Sander van Harmelen	c12f0355a7	Revert "Merge pull request #18980 from hashicorp/f-policy-output" ... This reverts commit f09c2db8d2, reversing changes made to 8394dc797d.	8 years ago
Sander van Harmelen	f09c2db8d2	Merge pull request #18980 from hashicorp/f-policy-output ... backend/remote: only show the full policy output when it fails	8 years ago
Sander van Harmelen	3979aec0ae	Ask to cancel a pending remote operation ... Except when a lock-timeout has exceeded or auto-approve is set.	8 years ago
Sander van Harmelen	37f5ab3500	Only show the full policy output when it fails ... If the policy passes, only show that instead of the full check output to prevent cluttering the output. So a passing policy will only show: ----------------------------------------------- Organization policy check: passed -----------------------------------------------	8 years ago
Sander van Harmelen	b28f47055d	backend/remote: extend mocks and add sentinel tests	8 years ago
Sander van Harmelen	2bd1040bbd	backend/remote: extend mocks and add apply tests	8 years ago