terraform

Commit Graph

Author	SHA1	Message	Date
Liam Cervante	ed822559e5	[Testing framework] Implement JSON view functionality for test command (#33400 )	3 years ago
Martin Atkins	696cd68913	command/views: Describe unknown collection bounds in diagnostics	3 years ago
CJ Horton	5d7864316e	Merge pull request #33160 from hashicorp/radditude/apply-counts Populate import counts during applies and clean up output	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
CJ Horton	bc084858b1	add import hooks for plan and apply Separate hooks used for the legacy import command for those used by the new import mechanism; also add apply output for imports.	3 years ago
hashicorp-copywrite[bot]	bb36298b21	[COMPLIANCE] Add Copyright and License Headers	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	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
UKEME BASSEY	7b34e3e743	redact sensitive output values in run logs	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
Martin Atkins	90ea7b0bc5	tfdiags: Treat unknown-related or sensitive-related messages differently By observing the sorts of questions people ask in the community, and the ways they ask them, we've inferred that various different people have been confused by Terraform reporting that a value won't be known until apply or that a value is sensitive as part of an error message when that message doesn't actually relate to the known-ness and sensitivity of any value. Quite reasonably, someone who sees Terraform discussing an unfamiliar concept like unknown values can assume that it must be somehow relevant to the problem being discussed, and so in that sense Terraform's current error messages are giving "too much information": information that isn't actually helpful in understanding the problem being described, and in the worst case is a distraction from understanding the problem being described. With that in mind then, here we introduce an explicit annotation on diagnostic objects that are directly talking about unknown values or sensitive values, and then the diagnostic renderer will react to that to avoid using the terminology "known only after apply" or "sensitive" in the generated diagnostic annotations unless we're rendering a message that is explicitly related to one of those topics. This ends up being a bit of a cross-cutting concern because the code that generates these diagnostics and the code that renders them are in separate packages and are not directly aware of each other. With that in mind, the logic for actually deciding for a particular diagnostic whether it's flagged in one of these special ways lives inside the tfdiags package as an intermediation point, which both the diagnostic generator (in the core package) and the diagnostic renderer can both depend on.	4 years ago
Martin Atkins	31aee9650e	command/format: Include function call information in diagnostics When an error occurs in a function call, the error message text often includes references to particular parameters in the function signature. This commit improves that reporting by also including a summary of the full function signature as part of the diagnostic context in that case, so a reader can see which parameter is which given that function arguments are always assigned positionally and so the parameter names do not appear in the caller's source code.	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
James Bardin	3a0a019521	round-trip replace triggers	4 years ago
Alisdair McDiarmid	b699391d04	json-output: Add change reasons to explain deletes The extra feedback information for why resource instance deletion is planned is now included in the streaming JSON UI output. We also add an explicit case for no-op actions to switch statements in this package to ensure exhaustiveness, for future linting.	5 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
James Bardin	863963e7a6	de-linting	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	71a067242d	json-output: Add resource drift to machine readable UI	5 years ago
Martin Atkins	70bc432f85	command/views/json: Never generate invalid diagnostic snippet offsets Because our snippet generator is trying to select whole lines to include in the snippet, it has some edge cases for odd situations where the relevant source range starts or ends directly at a newline, which were previously causing this logic to return out-of-bounds offsets into the code snippet string. Although arguably it'd be better for the original diagnostics to report more reasonable source ranges, it's better for us to report a slightly-inaccurate snippet than to crash altogether, and so we'll extend our existing range checks to check both bounds of the string and thus avoid downstreams having to deal with out-of-bounds indices. For completeness here I also added some similar logic to the human-oriented diagnostic formatter, which consumes the result of the JSON diagnostic builder. That's not really needed with the additional checks in the JSON diagnostic builder, but it's nice to reinforce that this code can't panic (in this way, at least) even if its input isn't valid.	5 years ago
James Bardin	55ebb2708c	remove IsMarked and ContainsMarked calls Make sure sensitivity checks are looking for specific marks rather than any marks at all.	5 years ago
James Bardin	d9dfd451ea	update to use typed sensitive marks	5 years ago
Alisdair McDiarmid	953738c128	command/views: Remove unused drift summary message This was dead code, and there is no clear way to retrieve this information, as we currently only derive the drift information as part of the rendering process.	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

27 Commits (7bee77bdd3dc67de0973e1c19bd5a1685dc805c0)