27 Commits (4338b75acd20a64c39bdba8d9028e06175bbdde2)

Author	SHA1	Message	Date
trujillo-adam	3b15748662	Apply suggestions from code review ... Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>	1 year ago
trujillo-adam	c9a871c238	completed seo refresh for internals	1 year ago
James Bardin	3a1a9408d9	fix Descendants spelling ... this has proliferated everywhere	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	ccb5596742	website: add "importing" to json plan format docs (#34269)	2 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
Ashlee Boyer	32f7b8ebd0	Migrating links to new format	3 years ago
Laura Pacilio	97f9cb1645	Remove unnecessary explanation	3 years ago
Laura Pacilio	a76b634f82	Update website/docs/internals/json-format.mdx	3 years ago
Laura Pacilio	2df5b5d8b5	Update website/docs/internals/json-format.mdx	4 years ago
Laura Pacilio	0247401266	Update website/docs/internals/json-format.mdx	4 years ago
Laura Pacilio	c9f5fdc6ba	Update website/docs/internals/json-format.mdx	4 years ago
Laura Pacilio	31a9fde330	take out currently	4 years ago
Laura Pacilio	cf47c71291	Revert "Revert "Remove future-facing statements"" ... This reverts commit cb975a5fff.	4 years ago
Laura Pacilio	cb975a5fff	Revert "Remove future-facing statements" ... This reverts commit 0a7e221a49.	4 years ago
Laura Pacilio	0a7e221a49	Remove future-facing statements	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
James Bardin	a0b66c87cc	Update website/docs/internals/json-format.mdx ... Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>	4 years ago
James Bardin	08fed6e296	Update website/docs/internals/json-format.mdx ... Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>	4 years ago
James Bardin	1e79f17ed2	Update website/docs/internals/json-format.mdx ... Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>	4 years ago
James Bardin	e58d74c0ca	update json plan docs with drift output ... Add "resource_drift" and "relevant_attributes" to the json plan documentation.	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
Alisdair McDiarmid	f5b90f84a8	jsonconfig: Improve provider configuration output ... When rendering configuration as JSON, we have a single map of provider configurations at the top level, since these are globally applicable. Each resource has an opaque key into this map which points at the configuration data for the provider. This commit fixes two bugs in this implementation: - Resources in non-root modules had an invalid provider config key, which meant that there was never a valid reference to the provider config block. These keys were prefixed with the local module name instead of the path to the module. This is now corrected. - Modules with passed provider configs would point to either an empty provider config block or one which is not present at all. This has been fixed so that these resources point to the provider config block from the calling module (or wherever up the module tree it was originally defined). We also add a "full_name" key-value pair to the provider config block, with the entire fully-qualified provider name including hostname and namespace.	4 years ago
Dylan Staley	21cbb5b392	migrate docs to mdx	4 years ago
Dylan Staley	0e48f58688	Revert "migrate docs to mdx" ... This reverts commit 3cb12b5a52.	4 years ago
Dylan Staley	3cb12b5a52	migrate docs to mdx	4 years ago