terraform

Commit Graph

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	4 months ago
Samsondeen	719aefdb89	tf query: ready list blocks for beta (#37619 )	9 months ago
Daniel Schmidt	90bdc053f2	add SRO message for planned action invocation	10 months ago
Daniel Schmidt	ecfbdaf18d	add number of action invocations to change summary	11 months ago
Kristin Laemmert	9256074c43	Actions in plan/changes (#37320 ) * Add actions to the plans and change * jsonplan - ignoring LinkedResources for now, those are not in the MVP * pausing here: we'll work on the plan rendering later	12 months ago
Daniel Banck	ab04e5cfec	Include list resource schemas in provider json schemas (TF-25497) (#37163 ) * Include list schemas in provider json schemas * Only include list schemas in experimental builds	1 year ago
Radek Simko	289a3568da	Address `go vet` 1.24 failures (#36485 ) * address go vet failures * avoid unnecessary .Error()	1 year ago
Martin Atkins	884e1fb2a4	terraform: Plans can be "complete" and "applyable" These ideas are both already implied by some logic elsewhere in the system, but until now we didn't have the decision logic centralized in a single place that could therefore evolve over time without necessarily always updating every caller together. We'll now have the modules runtime produce its own boolean ruling about each characteristic, which callers can rely on for the mechanical decision-making of whether to offer the user an "approve" prompt, and whether to remind the user after apply that it was an incomplete plan that will probably therefore need at least one more plan/apply round to converge. The "Applyable" flag directly replaces the previous method Plan.CanApply, with equivalent logic. Making this a field instead of a method means that we can freeze it as part of a saved plan, rather than recalculating it when we reload the plan, and we can export the field value in our export formats like JSON while ensuring it'll always be consistent with what Terraform is using internally. Callers can (and should) still use other context in the plan to return more tailored messages for specific situations they already know about that might be useful to users, but with these flags as a baseline callers can now just fall back to a generic presentation when encountering a situation they don't yet understand, rather than making the wrong decision and causing something strange to happen. That is: a lack of awareness of a new rule will now cause just a generic message in the UI, rather than incorrect behavior. This commit mostly just deals with populating the flags, and then all of the direct consequences of that on our various tests. Further changes to actually make use of these flags elsewhere in the system will follow in later commits, both in this repository and in other repositories.	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Nick Fagerlund	0df3c143bb	New plans.Quality type for display-relevant facts about a plan This commit replaces the existing jsonformat.PlanRendererOpt type with a new type with identical semantics, located in the plans package. We needed to be able to exchange the facts represented by `jsonformat.PlanRendererOpt` across some package boundaries, but the jsonformat package is implicated in too many dependency chains to be safe for that purpose! So, we had to make a new one. The plans package seems safe to import from all the places that must emit or accept this info, and already contains plans.Mode, which is effectively a sibling of this type.	3 years ago
Katy Moe	7ce5503c7a	views: fix wordwrap	3 years ago
kmoe	b4d1146f58	plannable import: improve gen config human plan output (#33194 ) * renderer: remove hard-coded config gen path * mention config gen file in plan next steps	3 years ago
Liam Cervante	81eb73731d	[Plannable Import] Implement streamed logs for plan (#33106 ) * [plannable import] embed the resource id within the changes * [Plannable Import] Implement streamed logs for -json plan * use latest structs * remove implementation plans from TODO	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	d818d7850d	Structured Renderer: use the new renderer when rendering the state in addition to the plan (#32629 ) * Use the new renderer when rendering the state * remove confusing and unneeded comment	3 years ago
Liam Cervante	8d61c5bfc4	Use the new structured renderer in place of the old diffs package (#32520 ) * Use the new structured renderer in place of the old diffs package * remove old plan tests * refresh only plans should show moved resources in the refresh section	3 years ago
Alisdair McDiarmid	b59b057591	json-output: Config-driven move support in JSON UI Add previous address information to the `planned_change` and `resource_drift` messages for the streaming JSON UI output of plan and apply operations. Here we also add a "move" action value to the `change` object of these messages, to represent a move-only operation. As part of this work we also simplify this code to use the plan's DriftedResources values instead of recomputing the drift from state.	5 years ago
Alisdair McDiarmid	3b33dc1105	json-output: Add output changes to plan logs Extend the outputs JSON log message to support an `action` field (and make the `type` and `value` fields optional). This allows us to emit a useful output change summary as part of the plan, bringing the JSON log output into parity with the text output. While we do have access to the before/after values in the output changes, attempting to wedge those into a structured log message is not appropriate. That level of detail can be extracted from the JSON plan output from `terraform show -json`.	5 years ago
Alisdair McDiarmid	a456d030db	Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.	5 years ago
Alisdair McDiarmid	71a067242d	json-output: Add resource drift to machine readable UI	5 years ago
Martin Atkins	36d0a50427	Move terraform/ to internal/terraform/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago
Martin Atkins	f40800b3a4	Move states/ to internal/states/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago
Martin Atkins	034e944070	Move plans/ to internal/plans/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago
Martin Atkins	ffe056bacb	Move command/ to internal/command/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago

24 Commits (f8fb61de12dea9ac94de3060a0d3e97ce9b5480b)