11 Commits (2cc94b4e89ccd47475c2b894e7cb9bd758ae73fc)

Author	SHA1	Message	Date
CJ Horton	98b81d3c50	add missing copyright headers	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	f74a8d16cf	[testing framework] implement expect_failures functionality (#33443)	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	9c87006c34	checks: hide check diagnostics during plans that will not wait for approval (#32938) ... * checks: filter out check diagnostics during certain plans * wrap diagnostics produced by check blocks in a dedicated check block diagnostic * address comments	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
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
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	8405f46bc5	tfdiags: Expose the "extra information" concept from HCL ... HCL's diagnostic model now includes the idea of "extra information" which works by attaching an initially-opaque interface value to each diagnostic and then asking callers to type-assert against that value to sniff for particular interfaces in order to discover additional machine-readable context about a certain diagnostic message. This commit echoes that idea into our tfdiags API, for now only for diagnostics that are backed by an hcl.Diagnostic. All other implementations of the diagnostic interface just always return nil, which means they never carry any "extra information". As is typical for our wrapping abstraction, we have here also a modified copy of HCL's helper function for conveniently probing a diagnostic for information of a particular type, designed to work with our diagnostic interface instead of HCL's concrete diagnostic type.	4 years ago
Alisdair McDiarmid	a103c65140	core: Eval pre/postconditions in refresh-only mode ... Evaluate precondition and postcondition blocks in refresh-only mode, but report any failures as warnings instead of errors. This ensures that any deviation from the contract defined by condition blocks is reported as early as possible, without preventing the completion of a state refresh operation. Prior to this commit, Terraform evaluated output preconditions and data source pre/postconditions as normal in refresh-only mode, while managed resource pre/postconditions were not evaluated at all. This omission could lead to confusing partial condition errors, or failure to detect undesired changes which would otherwise cause resources to become invalid. Reporting the failures as errors also meant that changes retrieved during refresh could cause the refresh operation to fail. This is also undesirable, as the primary purpose of the operation is to update local state. Precondition/postcondition checks are still valuable here, but should be informative rather than blocking.	4 years ago
Martin Atkins	05caff2ca3	Move tfdiags/ to internal/tfdiags/ ... 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