324 Commits (aff7d360e1fcd340ef356694eede9c565e1b1a33)

Author	SHA1	Message	Date
Liam Cervante	aff7d360e1	Add skeleton functions and API for refactored renderer (#32368) ... * prep for processing the structured run output * undo unwanted change to a json key * Add skeleton functions and API for refactored renderer * goimports * Fix documentation of the RenderOpts struct * Add README explaining implementation details for renderer and plans for future expansion * Update internal/command/jsonformat/README.md Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com> * address comments Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>	3 years ago
Liam Cervante	b917154a97	Make required JSON structured output structures public for processing (#32367) ... * prep for processing the structured run output * undo unwanted change to a json key	3 years ago
James Bardin	721df0e68d	Merge pull request #32395 from hashicorp/jbardin/plan-output-on-error ... Always show and store planned actions and checks even when planning fails	3 years ago
James Bardin	a6098b67fa	fix test state	3 years ago
James Bardin	25ac4d33e4	Merge pull request #31633 from brittandeyoung/f-workspace-selectornew ... New Terraform Workspace select flag: `-or-create`	3 years ago
Brittan DeYoung	8881418c99	Update internal/command/workspace_select.go ... Co-authored-by: James Bardin <j.bardin@gmail.com>	3 years ago
James Bardin	d60d247e40	Merge pull request #31318 from twittyc/twittyc/terraformWorkspaceInvalidArgsReturnsNon0 ... Bug fix: Terraform workspace command returns zero exit code when given an invalid argument.	3 years ago
James Bardin	76d5e4a9cb	add command test for errored plan	3 years ago
James Bardin	5aa088e385	remove -always-out ... Make writing a plan file the default. We already create plans which have no changes so the plan result would need to be checked in automation, so having plans with errors should not pose a problem. If we find workflows which cannot handle a plan that can't be applied, we can reevaluate the need for a specialized flag. In the meantime, it feels more logical that the plan output would always describe the result of the plan, even if that included errors.	3 years ago
Martin Atkins	4660dacd59	command: Prototype of handling errored plans ... This is a prototype of how the CLI layer might make use of Terraform Core's ability to produce a partial plan if it encounters an error during planning, with two new situations: - When using local CLI workflow, Terraform will show the partial plan before showing any errors. - "terraform plan" has a new option -always-out=..., which is similar to the existing -out=... but additionally instructs Terraform to produce a plan file even if the plan is incomplete due to errors. This means that the plan can still be inspected by external UI implementations. This is just a prototype to explore how these parts might fit together. It's not a complete implementation and so should not be shipped. In particular, it doesn't include any mention of a plan being incomplete in the "terraform show -json" output or in the "terraform plan -json" output, both of which would be required for a complete solution.	3 years ago
James Bardin	404b284911	Merge pull request #31757 from hashicorp/jbardin/terraform-data ... New `terraform_data` managed resource to replace `null_resource`	3 years ago
Conor Evans	e206d4e83e	fix(unlock): amend force-unlock description (#32363) ... Signed-off-by: Conor Evans <coevans@tcd.ie> Signed-off-by: Conor Evans <coevans@tcd.ie>	3 years ago
James Bardin	d0d6501c1f	s/trigger/triggers_replace/ ... Rename `triggers` to be more descriptive, making it similar to `replace_triggered_by`.	3 years ago
James Bardin	58e15c7f0e	add terraform_data e2e test	3 years ago
alisdair	ec6451a82a	Merge pull request #31999 from JarrettSpiker/jspiker/workspace-delete-rum-docs ... Update workspace delete command docs to reference RUM vs empty state	3 years ago
Jarrett Spiker	21d98697cb	Add manual line breaks to workspace delete command help text	3 years ago
Jarrett Spiker	060255a9d5	Use safe or force workspace delete for cloud backend	3 years ago
Martin Atkins	d0a35c60a7	providercache: Ignore lock-mismatching global cache entries ... When we originally introduced the trust-on-first-use checksum locking mechanism in v0.14, we had to make some tricky decisions about how it should interact with the pre-existing optional read-through global cache of provider packages: The global cache essentially conflicts with the checksum locking because if the needed provider is already in the cache then Terraform skips installing the provider from upstream and therefore misses the opportunity to capture the signed checksums published by the provider developer. We can't use the signed checksums to verify a cache entry because the origin registry protocol is still using the legacy ziphash scheme and that is only usable for the original zipped provider packages and not for the unpacked-layout cache directory. Therefore we decided to prioritize the existing cache directory behavior at the expense of the lock file behavior, making Terraform produce an incomplete lock file in that case. Now that we've had some real-world experience with the lock file mechanism, we can see that the chosen compromise was not ideal because it causes "terraform init" to behave significantly differently in its lock file update behavior depending on whether or not a particular provider is already cached. By robbing Terraform of its opportunity to fetch the official checksums, Terraform must generate a lock file that is inherently non-portable, which is problematic for any team which works with the same Terraform configuration on multiple different platforms. This change addresses that problem by essentially flipping the decision so that we'll prioritize the lock file behavior over the provider cache behavior. Now a global cache entry is eligible for use if and only if the lock file already contains a checksum that matches the cache entry. This means that the first time a particular configuration sees a new provider it will always be fetched from the configured installation source (typically the origin registry) and record the checksums from that source. On subsequent installs of the same provider version already locked, Terraform will then consider the cache entry to be eligible and skip re-downloading the same package. This intentionally makes the global cache mechanism subordinate to the lock file mechanism: the lock file must be populated in order for the global cache to be effective. For those who have many separate configurations which all refer to the same provider version, they will need to re-download the provider once for each configuration in order to gather the information needed to populate the lock file, whereas before they would have only downloaded it for the _first_ configuration using that provider. This should therefore remove the most significant cause of folks ending up with incomplete lock files that don't work for colleagues using other platforms, and the expense of bypassing the cache for the first use of each new package with each new configuration. This tradeoff seems reasonable because otherwise such users would inevitably need to run "terraform providers lock" separately anyway, and that command _always_ bypasses the cache. Although this change does decrease the hit rate of the cache, if we subtract the never-cached downloads caused by "terraform providers lock" then this is a net benefit overall, and does the right thing by default without the need to run a separate command.	4 years ago
Brandon Croft	bd744ad4e9	Unify all sensitive value plan output as "(sensitive value)" ... Previously, there was mixed usage of "(sensitive)" and "(sensitive value)" and even though it was more common to see "(sensitive)", the thought is that it's a value we are hiding rather than describing something already shown.	4 years ago
Brandon Croft	076fccd8e7	fix: don't reveal nested attributes with sensitive schema	4 years ago
Jarrett Spiker	3d5dba5c09	Update internal/command/workspace_delete.go ... Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>	4 years ago
Jarrett Spiker	9d2e8a4c7e	Update workspace delete command docs and help to reference RUM instead of non-empty state	4 years ago
UKEME BASSEY	7b34e3e743	redact sensitive output values in run logs	4 years ago
Megan Bang	72ba8a869e	removes EnableForcePush and other unrelated code	4 years ago
Brittan DeYoung	11da5afb5e	Spelling Error fixes	4 years ago
Brittan DeYoung	409bd667c3	workspace: update envDoesNotExist message	4 years ago
Brittan DeYoung	7110ec8b0c	select: Fix capitalization of help text	4 years ago
Brittan DeYoung	7d0d352eed	select: -or-create helptext and conditional output	4 years ago
Brittan DeYoung	5932540be3	New Terraform Workspace select flag:	4 years ago
kmoe	ba113ff2cd	add destroy option to terraform apply help text (#31714)	4 years ago
megan07	cb340207d8	Merge pull request #31698 from hashicorp/megan_tf563 ... Send the JSON state representation to Cloud backend (when available)	4 years ago
Megan Bang	37b7e6ebce	don't check diags for errors	4 years ago
Megan Bang	4d749e2813	add warning to diags and show at the end of each command	4 years ago
Megan Bang	5eaa4c45c0	fix imports	4 years ago
Megan Bang	de8bd5826f	first part of code review comments	4 years ago
kmoe	dec48a8510	plans: indicate when resource deleted due to move (#31695) ... Add a new ChangeReason, ReasonDeleteBecauseNoMoveTarget, to provide better information in cases where a planned deletion is due to moving a resource to a target not in configuration. Consider a case in which a resource instance exists in state at address A, and the user adds a moved block to move A to address B. Whether by the user's intention or not, address B does not exist in configuration. Terraform combines the move from A to B, and the lack of configuration for B, into a single delete action for the (previously nonexistent) entity B. Prior to this commit, the Terraform plan will report that resource B will be destroyed because it does not exist in configuration, without explicitly connecting this to the move. This commit provides the user an additional clue as to what has happened, in a case in which Terraform has elided a user's action and inaction into one potentially destructive change.	4 years ago
Megan Bang	b504dd1489	update from code consistency checks	4 years ago
Megan Bang	485a1f6777	remove test for error	4 years ago
Megan Bang	bddf6a9b34	updating to use the latest version of cloud/state.go and just pass schemas along to PersistState in the remote state	4 years ago
Megan Bang	b572e57fb3	refactor GetSchemas to include an option to pass in a config	4 years ago
Megan Bang	40263cd861	undo taint test changes	4 years ago
Megan Bang	00cc1ea26d	refactor getSchemas	4 years ago
Martin Atkins	71dec301a2	command/jsonchecks: Mark check result objects as experimental ... This is a clumsy way to do this, but a pragmatic way to inform potential consumers that this part of the format is not yet finalized without having to read the docs to see our warning about that. We need to get some practical experience with a few different consumers making use of this format before we can be confident that it's designed appropriately. We're not _expecting_ to break it, but we'd like to leave the opportunity open in case we quickly learn that there's something non-ideal about this design.	4 years ago
Martin Atkins	a8c255c779	command/jsonstate: Include check results in JSON state report	4 years ago
Martin Atkins	0e4e9f7706	addrs: Be explicit about checkable object address kinds ... Previously we were attempting to infer the checkable object address kind of a given address by whether it included "output" in the position where a resource type name would otherwise go. That was already potentially risky because we've historically not prevented a resource type named "output", and it's also a forward-compatibility hazard in case we introduce additional object kinds with entirely-new addressing schemes in future. Given that, we'll instead always be explicit about what kind of address we're storing in a wire or file format, so that we can make sure to always use the intended parser when reading an address back into memory, or return an error if we encounter a kind we're not familiar with.	4 years ago
Martin Atkins	fe7e6f970e	command/jsonplan: Include new-style check results in JSON plan output ... This is a new-shaped representation of check results which follows the two-tiered structure of static objects and dynamic instances of objects, thereby allowing consumers to see which checkable objects exist in the configuration even if a dynamic evaluation error prevented actually expanding them all to determine their declared instances. Eventually we'll include this in the state too, but this initially adds it only to the plan in order to replace the now-deprecated experimental conditions result that was present but undocumented in Terraform v1.2.	4 years ago
Martin Atkins	9e4861adbb	states: Two-level representation of check results ... A significant goal of the design changes around checks in earlier commits (with the introduction of package "checks") was to allow us to differentiate between a configuration object that we didn't expand at all due to an upstream error, which has _unknown_ check status, and a configuration object that expanded to zero dynamic objects, which therefore has a _passing_ check status. However, our initial lowering of checks.State into states.CheckResults stayed with the older model of just recording each leaf check in isolation, without any tracking of the containers. This commit therefore lightly reworks our representation of check results in the state and plan with two main goals: - The results are grouped by the static configuration object they came from, and we capture an aggregate status for each of those so that we can differentiate an unknown aggregate result from a passing aggregate result which has zero dynamic associated objects. - The granularity of results is whole checkable objects rather than individual checks, because checkable objects have durable addresses between runs, but individual checks for an object are more of a syntactic convenience to make it easier for module authors to declare many independent conditions that each have their own error messages. Since v1.2 exposed some details of our checks model into the JSON plan output there are some unanswered questions here about how we can shift to reporting in the two-level heirarchy described above. For now I've preserved structural compatibility but not semantic compatibility: any parser that was written against that format should still function but will now see fewer results. We'll revisit this in a later commit and consider other structures and what to do about our compatibility constraint on the v1.2 structure. Otherwise though, this is an internal-only change which preserves all of the existing main behaviors of conditions as before, and just gets us ready to build user-facing features in terms of this new structure.	4 years ago
Martin Atkins	3785619f93	core: Use the new checks package for condition tracking ... The "checks" package is an expansion what we previously called plans.Conditions to accommodate a new requirement that we be able to track which checks we're expecting to run even if we don't actually get around to running them, which will be helpful when we start using checks as part of our module testing story because test reporting tools appreciate there being a relatively consistent set of test cases from one run to the next. So far this should be essentially a no-op change from an external functionality standpoint, aside from some minor adjustments to how we report some of the error and warning cases from condition evaluation in light of the fact that the "checks" package can now track errors as a different outcome than a failure of a valid check. As is often the case with anything which changes what we track in the EvalContext and persist between plan and apply, Terraform Core is pretty brittle and so this had knock-on effects elsewhere too. Again, the goal is for these changes to not create any material externally-visible difference, and just to accommodate the new assumption that there will always be a "checks" object available for tracking during a graph walk.	4 years ago
Megan Bang	d5decc2407	update flow of schema checking	4 years ago
Megan Bang	12e3560d21	check for cloud integration mode	4 years ago