68 Commits (8fd8a48a06af33d3a3614b4b48768bd1516632fe)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Daniel Schmidt	ad4371342f	track partial expanded action invocations through deferred action invocation ... like we do it for resources just simpler because we don't have layered addrs maps	8 months ago
Daniel Schmidt	dffeeec81e	partially expand triggers as well	8 months ago
Daniel Schmidt	14c83aa7ee	allow reporting action invocations as deferred	8 months ago
Daniel Schmidt	eb26b72d55	display lifecycle triggered actions aside their triggering resources	9 months ago
Daniel Schmidt	c2b35e7ee7	remove duplicate place to store action invocations from plan	9 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	9 months ago
Daniel Banck	0aa4ce972d	Add resource identities to plan file and JSON output (#36903)	1 year ago
Daniel Schmidt	fec6e4b552	send resource identities to provider calls	1 year ago
Daniel Banck	b2b42c0fb4	Store resource identities in state (TF-23255) (#36464) ... * Persist resource identity in Terraform state * make syncdeps * Move identity schema merging closer to the protocol * mock GetResourceIdentitySchemas * Fix identity refresh tests * Add more tests * Change grcpwrap upgrade identity * Review feedback * Remove unnecessary version conversion * Check if GetResourceIdentitySchemas RPC call is implemented * Update function signature docs * Adapt protocol changes * Check unimplemented error for identities in GetSchema	1 year ago
Liam Cervante	f1bd8df9b0	jsonplan: sort the relevant attributes in the correct plan (#36093)	1 year ago
Liam Cervante	36d7e8706f	jsonplan: deterministic relevant attribute order (#36076) ... * jsonplan: deterministic relevant attribute order * simplify sort function	1 year ago
James Bardin	bc750192e4	POC for always using decoded changes in core ... We should not need to encode and decode change values within core, since the encoded version is only technically needed for serialization. This pattern stems from the conversion to current changes system, but back then we did not have easy access to the correct schemas at the time to encode and decode the entire set of changes. Moving the core handling of changes to only use the decoded values will drastically improve evaluation efficiency, removing a round trip through encoded values for every resource reference.	2 years ago
Daniel Schmidt	4afb3b2b48	jsonformat: render deferred actions	2 years ago
Liam Cervante	471bddf3ba	json plan: update resource index and import ids to support unknown values (#35518)	2 years ago
Liam Cervante	b718c55b13	deferred actions: include deferred resources within JSON plan output (#35065) ... * deferred actions: include deferred resources within JSON plan output * address comments	2 years ago
Martin Atkins	30e2fd6525	Handle marks a little more consistently ... In the very first implementation of "sensitive values" we were unfortunately not disciplined about separating the idea of "marked value" from the idea of "sensitive value" (where the latter is a subset of the former). The first implementation just assumed that any marking whatsoever meant "sensitive". We later improved that by adding the marks package and the marks.Sensitive value to standardize on the representation of "sensitive value" as being a value marked with _that specific mark_. However, we did not perform a thorough review of all of the mark-handling codepaths to make sure they all agreed on that definition. In particular, the state and plan models were both designed as if they supported arbitrary marks but then in practice marks other than marks.Sensitive would be handled in various inconsistent ways: dropped entirely, or interpreted as if marks.Sensitive, and possibly do so inconsistently when a value is used only in memory vs. round-tripped through a wire/file format. The goal of this commit is to resolve those oddities so that there are now two possible situations: - General mark handling: some codepaths genuinely handle marks generically, by transporting them from input value to output value in a way consistent with how cty itself deals with marks. This is the ideal case because it means we can add new marks in future and assume these codepaths will handle them correctly without any further modifications. - Sensitive-only mark preservation: the codepaths that interact with our wire protocols and file formats typically have only specialized support for sensitive values in particular, and lack support for any other marks. Those codepaths are now subject to a new rule where they must return an error if asked to deal with any other mark, so that if we introduce new marks in future we'll be forced either to define how we'll avoid those markings reaching the file/wire formats or extend the file/wire formats to support the new marks. Some new helper functions in package marks are intended to standardize how we deal with the "sensitive values only" situations, in the hope that this will make it easier to keep things consistent as the codebase evolves in future. In practice the modules runtime only ever uses marks.Sensitive as a mark today, so all of these checks are effectively covering "should never happen" cases. The only other mark Terraform uses is an implementation detail of "terraform console" and does not interact with any of the codepaths that only support sensitive values in particular.	2 years ago
thirdkeyword	8284cde302	remove repetitive words ... Signed-off-by: thirdkeyword <fliterdashen@gmail.com>	2 years 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
kmoe	8f3aa0e099	jsonformat: render forget-only attr changes as no-op (#34403) ... * jsonplan: document forget actions * jsonformat: format forget changes as no-op Previous to this commit, forget-only actions (i.e. "forget", not "create then forget") would be rendered using the forget action symbol for the top-level resource, and the delete action symbol for each resource attribute, with a new value of "null". This attribute rendering is identical to that for resource deletion, which might suggest to some users that Terraform plans to delete the resource, not just remove it from state. This commit tweaks the renderer so forget-only changes render as no-ops but with the forget action symbol and resource change comment.	2 years ago
kmoe	a718f70f85	Add removed block (#34251) ... * terraform: remove redundant code NodeDestroyResourceInstance is never instantiated with a DeposedKey of anything other than states.NotDeposed, so the deleted code is never run. Deposed objects get a NodeDestroyDeposedResourceInstanceObject instead. * tfdiags: add helper func * configs: introduce removed block type * terraform: add forget action * renderer: render forget actions * terraform: deposed objects can be forgotten Deposed objects encountered during planning spawn NodePlanDeposedResourceInstanceObject, which previously generated a destroy change. Now it will generate a forget change if the deposed object is a forget target, and a destroy change otherwise. The apply graph gains a new node type, NodeForgetDeposedResourceInstanceObject, whose execution simply removes the object from the state. * configs: add RemoveTarget address type * terraform: modules can be forgotten * terraform: error if removed obj still in config * tests: better error on restore state fail * Update CHANGELOG.md	2 years ago
Liam Cervante	2ea141b3f4	Embed the schemas directly in the testing framework JSON verbose outputs (#33755)	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	6882dd9530	testing framework: introduce test command optional flags (#33504) ... * testing framework: introduce test command optional flags * address consistency checks	3 years ago
Andrew Hickman	49f99db1c2	`terraform show -json`: Add Errored field to output for plan (#33372) ... * Add Errored field to JSON output * Fix test error message	3 years ago
Liam Cervante	4d837df546	Plannable import: Add generated config to JSON and human-readable plan output (#33154) ... * command: keep our promises * remove some nil config checks Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time. * add GeneratedConfig to plan changes objects Add a new GeneratedConfig field alongside Importing in plan changes. * add config generation package The genconfig package implements HCL config generation from provider state values. Thanks to @mildwonkey whose implementation of terraform add is the basis for this package. * generate config during plan If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node. The generated config string is attached to the change emitted by the plan. * complete config generation prototype, and add tests * Plannable import: Add generated config to json and human-readable plan output --------- Co-authored-by: Katy Moe <katy@katy.moe>	3 years ago
Liam Cervante	54c1c1162f	[Plannable Import] Implement human-readable plan rendering (#33113) ... * [plannable import] embed the resource id within the changes * add the plannable imports to the json and human plans * latest importing struct	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	aae6990d38	Add native `plantimestamp` function to Terraform (#32980) ... * add plantimestamp function * documentation * add missing links * fix typo	3 years ago
Liam Cervante	978263efe9	Checks: Introduce check blocks into the terraform node and transform graph (#32735) ... * Add support for scoped resources * refactor existing checks addrs and add check block addr * Add configuration for check blocks * introduce check blocks into the terraform node and transform graph * address comments * address comments * don't execute checks during destroy operations * don't even include check nodes for destroy operations	3 years ago
Liam Cervante	d212a72d1d	structured run output: impose canonical ordering on jsonstate and jsonplan packages (#32649)	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	6dc49150b7	Structured Plan Renderer: Read the data source schemas from the right place (#32532) ... * read the data source schemas from the right place * address comments and add test	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
Liam Cervante	e015b15f12	Structured Plan Renderer: Remove attributes that do not match the relevant attributes filter (#32509) ... * remove attributes that do not match the relevant attributes filter * fix formatting * fix renderer function, don't drop irrelevant attributes just mark them as no-ops * fix imports	3 years ago
Liam Cervante	95782f2491	Structured plan renderer: Implement the main functionality for the renderer (#32496) ... * raw unmodified broken tests * tests execute, no panics * fix whitespace differences * fix all the tests * fix tests * actually fix tests * add missing plan metadata into the renderer * address comments * complete merge * remove TODO raising questions about outputs, they are fixed * missing bold on plan	3 years ago
Liam Cervante	af0ff90d6e	Remove outputs from the jsonplan that are not from the root module (#32503)	3 years ago
James Bardin	96b1318167	remove deprecated condition_results from plan	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
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
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
Martin Atkins	783a07d9e8	build: Use Go 1.19 ... Go 1.19's "fmt" has some awareness of the new doc comment formatting conventions and adjusts the presentation of the source comments to make it clearer how godoc would interpret them. Therefore this commit includes various updates made by "go fmt" to acheve that. In line with our usual convention that we make stylistic/grammar/spelling tweaks typically only when we're "in the area" changing something else anyway, I also took this opportunity to review most of the comments that this updated to see if there were any other opportunities to improve them.	4 years ago
Alisdair McDiarmid	c7bc82bd87	Merge pull request #31235 from hashicorp/alisdair/json-plan-unknown-outputs ... json-output: Extended detail for unknown outputs	4 years ago
Alisdair McDiarmid	9497b2cd6f	json-output: Fix unknowns for tuples and sets ... The JSON output for sequences previously omitted unknown values for tuples and sets, which made it impossible to interpret the corresponding unknown marks. For example, consider this resource: resource "example_resource" "example" { tags = toset(["alpha", timestamp(), "charlie"]) } This would previously be encoded in JSON as: "after": { "tags": ["alpha", "charlie"] }, "after_unknown": { "id": true, "tags": [false, true, false] }, That is, the timestamp value would be omitted from the output altogether, while the corresponding unknown marks would include a value for each of the set members. This commit changes the behaviour to: "after": { "tags": ["alpha", null, "charlie"] }, "after_unknown": { "id": true, "tags": [false, true, false] }, This aligns tuples and sets with the prior behaviour for lists, and makes it clear which elements are known and which are unknown.	4 years ago
Alisdair McDiarmid	48d64eabb2	json-output: Extended detail for unknown outputs ... Planned output changes are represented in the JSON output format using the same change object as planned resource changes. This structure includes an `after` value and a parallel `after_unknown` value, which can be combined to determine which specific parts of a value are known only at apply time. Previously, structured output values would be marked in the JSON plan as coarsely known or unknown, even if only some subset of the structure will be known only at apply time. This simplification was unnecessary, and this commit reuses the same logic for resource changes to give more information to consumers of this format. For example, consider this output: output "bar" { value = tolist([ "hello", timestamp(), "world", ]) } The plan output for this output would be: + bar = [ + "hello", + (known after apply), + "world", ] For the same plan, the JSON output was previously: "bar": { "actions": [ "create" ], "before": null, "after_unknown": true, "before_sensitive": false, "after_sensitive": false } After this commit, the output is instead: "bar": { "actions": [ "create" ], "before": null, "after": [ "hello", null, "world" ], "after_unknown": [ false, true, false ], "before_sensitive": false, "after_sensitive": false }	4 years ago
Martin Atkins	4cffff24b1	core: Report reason for deferring data read until apply ... We have two different reasons why a data resource might be read only during apply, rather than during planning as usual: the configuration contains unknown values, or the data resource as a whole depends on a managed resource which itself has a change pending. However, we didn't previously distinguish these two in a way that allowed the UI to describe the difference, and so we confusingly reported both as "config refers to values not yet known", which in turn led to a number of reasonable questions about why Terraform was claiming that but then immediately below showing the configuration entirely known. Now we'll use our existing "ActionReason" mechanism to tell the UI layer which of the two reasons applies to a particular data resource instance. The "dependency pending" situation tends to happen in conjunction with "config unknown", so we'll prefer to refer that the configuration is unknown if both are true.	4 years ago
Alisdair McDiarmid	12c8f9498c	json-output: Add output type to JSON format ... Previously the supported JSON plan and state formats included only serialized output values, which was a lossy serialization of the Terraform type system. This commit adds a type field in the usual cty JSON format, which allows reconstitution of the original value. For example, previously a list(string) and a set(string) containing the same values were indistinguishable. This change serializes these as follows: { "value": ["a","b","c"], "type": ["list","string"] } and: { "value": ["a","b","c"], "type": ["set","string"] }	4 years ago
James Bardin	3a0a019521	round-trip replace triggers	4 years ago