17 Commits (3679de0630ffbe67fa8d2ff299891dfdcb01cd6a)

Author	SHA1	Message	Date
Martin Atkins	b802237e03	plans: Track an optional extra "reason" for some planned actions ... Previously we were repeating some logic in the UI layer in order to recover relevant additional context about a change to report to a user. In order to help keep things consistent, and to have a clearer path for adding more such things in the future, here we capture this user-facing idea of an "action reason" within the plan model, and then use that directly in order to decide how to describe the change to the user. For the moment the "tainted" situation is the only one that gets a special message, matching what we had before, but we can expand on this in future in order to give better feedback about the other replace situations too. This also preemptively includes the "replacing by request" reason, which is currently not reachable but will be used in the near future as part of implementing the -replace=... plan command line option to allow forcing a particular object to be replaced. So far we don't have any special reasons for anything other than replacing, which makes sense because replacing is the only one that is in a sense a special case of another action (Update), but this could expand to other kinds of reasons in the future, such as explaining which of the few different reasons a data source read might be deferred until the apply step.	5 years ago
Alisdair McDiarmid	5e30d58dc2	command/jsonplan: Add output change sensitivity ... When an output value changes, we have a small amount of information we can convey about its sensitivity. If either the output was previously marked sensitive, or is currently marked sensitive in the config, this is tracked in the output change data. This commit encodes this boolean in the change struct's `before_sensitive` and `after_sensitive` fields, in the a way which matches resource value sensitivity. Since we have so little information to work with, these two values will always be booleans, and always equal each. This is logically consistent with how else we want to obscure sensitive data: a changing output which was or is marked sensitive should not have the value shown in human-readable output.	5 years ago
Alisdair McDiarmid	63613ca1b0	command/jsonconfig: Add variable sensitive flag	5 years ago
Alisdair McDiarmid	e27aacebf9	command/jsonplan: Add sensitive value mapping data ... Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are values with similar structure to `before` and `after` which encode the presence of sensitive values in a planned change. These should be used to obscure sensitive values from human-readable output. These values follow the same structure as the `before` and `after` values, replacing sensitive values with `true`, and non-sensitive values with `false`. Following the `after_unknown` precedent, we omit non-sensitive `false` values for object attributes/map values, to make serialization more compact. One difference from `after_unknown` is that a sensitive complex value (collection or structural type) is replaced with `true`. If the complex value itself is sensitive, all of its contents should be obscured.	5 years ago
Alisdair McDiarmid	7cae76383a	cli: Fix for provider requirements in JSON plan ... The JSON plan output format includes a serialized, simplified version of the configuration. One component of this config is a map of provider configurations, which includes version constraints. Until now, only version constraints specified in the provider config blocks were exposed in the JSON plan output. This is a deprecated method of specifying provider versions, and the recommended use of a required_providers block resulted in the version constraints being omitted. This commit fixes this with two changes: - When processing the provider configurations from a module, output the fully-merged version constraints for the entire module, instead of any constraints set in the provider configuration block itself; - After all provider configurations are processed, iterate over the required_providers entries to ensure that any configuration-less providers are output to the JSON plan too. No changes are necessary to the structure of the JSON plan output, so this is effectively a semantic level bug fix.	5 years ago
James Bardin	d2514a9abd	update new outputs plan json	6 years ago
James Bardin	3b3ff98356	Revert "fix show -json tests" ... This reverts commit e54949f2e1. Changes incorrectly applied to the planned state tests	6 years ago
James Bardin	e54949f2e1	fix show -json tests ... The prior state recorded in the plans did not match the actual prior state. Make the plans and state match depending on whether there was existing state or not.	6 years ago
Cameron Stitt	54e32652f7	Ensure depends_on is in module calls for config	6 years ago
Kristin Laemmert	f8e3456867	command/show: fix bug displaying provider config in json output of tf plan (#25577) ... A lingering FIXME caused missing configuration from provider config blocks in the json output of terraform plan. This fixes the regression and adds a test. For the sake of testing, I added an optional attribute to the show test provider, which resulted in the providers schema test getting an update - not a bad addition, but we can always add a test-specific provider schema as needed.	6 years ago
Kristin Laemmert	27a794062e	Mildwonkey/command tests (#24535) ... * command: refactor testBackendState to write states.State testBackendState was using the older terraform.State format, which is no longer sufficient for most tests since the state upgrader does not encode provider FQNs automatically. Users will run `terraform 0.13upgrade` to update their state to include provider FQNs in resources, but tests need to use the modern state format instead of relying on the automatic upgrade. * plan tests passing * graph tests passing * json packages test update * command test updates * update show test fixtures * state show tests passing	6 years ago
Kristin Laemmert	7f1b0a4681	command/jsonstate: fix inconsistency with resource address (#24256) ... * command/jsonstate: fix inconsistency with resource address Resource addresses in state output were not including index for instances created with for_each or count, while the index was appearing in the plan output. This PR fixes that inconsistency, adds tests, and updates the existing tests. Fixes #24110 * add tests showing expected prior state resource addressing * added example of show json state output with modules	6 years ago
Pam Selle	c249943360	Module Expansion: Part 2 (#24154) ... * WIP: dynamic expand * WIP: add variable and local support * WIP: outputs * WIP: Add referencer * String representation, fixing tests it impacts * Fixes TestContext2Apply_outputOrphanModule * Fix TestContext2Apply_plannedDestroyInterpolatedCount * Update DestroyOutputTransformer and associated types to reflect PlannableOutputs * Remove comment about locals * Remove module count enablement * Removes allowing count for modules, and reverts the test, while adding a Skip()'d test that works when you re-enable the config * update TargetDownstream signature to match master * remove unnecessary method Co-authored-by: James Bardin <j.bardin@gmail.com>	6 years ago
Kristin Laemmert	47a16b0937	addrs: embed Provider in AbsProviderConfig instead of Type ... a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.	6 years ago
Kristin Laemmert	4b10a6e1bf	command/jsonplan: fix bug with nested modules output (#23092) ... `marshalPlannedValues` builds a map of modules to their children in order to output the resource changes in a tree. The map was built from the list of resource changes. However if a module had no resources itself, and only called another module (a very normal case), that module would not get added to the map causing none of its children to be output in `planned_values`. This PR adds a walk up through a given module's ancestors to ensure that each module, even those without resources, would be added.	7 years ago
James Bardin	e4640a43d7	fix show-json test to expect error from nested mod ... One of the show json command tests expected no error when presented with an invalid configuration in a nested module. Modify the test created in PR #21569 so that it can still verify there is no panic, but now expect an error from init.	7 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago