terraform

Commit Graph

Author	SHA1	Message	Date
Alisdair McDiarmid	b5cfc0bb8b	core: Fix sensitive variable validation errors Variable validation error message expressions which generated sensitive values would previously crash. This commit updates the logic to align with preconditions and postconditions, eliding sensitive error message values and adding a separate diagnostic explaining why.	4 years ago
Alisdair McDiarmid	6db174e210	core: Fix crash for sensitive values in conditions Precondition and postcondition blocks which evaluated expressions resulting in sensitive values would previously crash. This commit fixes the crashes, and adds an additional diagnostic if the error message expression produces a sensitive value (which we also elide).	4 years ago
Alisdair McDiarmid	6cd0876596	Merge pull request #30658 from hashicorp/alisdair/preconditions-postconditions-refresh-only core: Eval pre/postconditions in refresh-only mode	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
James Bardin	45e2a410f7	Merge pull request #30656 from hashicorp/jbardin/always-validate Always validate the graph	4 years ago
James Bardin	b1de94a176	make sure CBD test graphs are valid The graphs used for the CBD tests wouldn't validate because they skipped adding the root module node. Re add the root module transformer and transitive reduction transformer to the build steps, and match the new reduced output in the test fixtures.	4 years ago
James Bardin	0bc69d64ec	always validate all graphs Complete the removal of the Validate option for graph building. There is no case where we want to allow an invalid graph, as the primary reason for validation is to ensure we have no cycles, and we can't walk a graph with cycles. The only code which specifically relied on there being no validation was a test to ensure the Validate flag prevented it.	4 years ago
Alisdair McDiarmid	2ee64dc7e0	Merge pull request #30645 from hashicorp/alisdair/preconditions-postconditions-expanded-resources core: Fix expanded condition block validation	4 years ago
Laura Pacilio	821064edd3	Merge pull request #30637 from kderck/patch-2 Change aws.dest to aws.dst	4 years ago
Laura Pacilio	63fa72022f	Merge pull request #30631 from savage-tm/patch-1 Document logical operators not short-circuiting	4 years ago
Alisdair McDiarmid	ef0d859af7	core: Refactor stub repetition data generation	4 years ago
Alisdair McDiarmid	ad995322e1	core: Fix expanded condition block validation The previous precondition/postcondition block validation implementation failed if the enclosing resource was expanded. This commit fixes this by generating appropriate placeholder instance data for the resource, depending on whether `count` or `for_each` is used.	4 years ago
Martin Atkins	2aa1613c19	Update CHANGELOG.md	4 years ago
Martin Atkins	1879a39d2d	configs: Refined error messages for mismatched provider passing This set of diagnostic messages is under a number of unusual constraints that make them tough to get right: - They are discussing a couple finicky concepts which authors are likely to be encountering for the first time in these error messages: the idea of "local names" for providers, the relationship between those and provider source addresses, and additional ("aliased") provider configurations. - They are reporting concerns that span across a module call boundary, and so need to take care to be clear about whether they are talking about a problem in the caller or a problem in the callee. - Some of them are effectively deprecation warnings for features that might be in use by a third-party module that the user doesn't control, in which case they have no recourse to address them aside from opening a feature request with the upstream module maintainer. - Terraform has, for backward-compatibility reasons, a lot of implied default behaviors regarding providers and provider configurations, and these errors can arise in situations where Terraform's assumptions don't match the author's intent, and so we need to be careful to explain what Terraform assumed in order to make the messages understandable. After seeing some confusion with these messages in the community, and being somewhat confused by some of them myself, I decided to try to edit them a bit for consistency of terminology (both between the messages and with terminology in our docs), being explicit about caller vs. callee by naming them in the messages, and making explicit what would otherwise be implicit with regard to the correspondences between provider source addresses and local names. My assumed audience for all of these messages is the author of the caller module, because it's the caller who is responsible for creating the relationship between caller and callee. As much as possible I tried to make the messages include specific actions for that author to take to quiet the warning or fix the error, but some of the warnings are only fixable by the callee's maintainer and so those messages are, in effect, a suggestion to send a request to the author to stop using a deprecated feature. I think these new messages are also not ideal by any means, because it's just tough to pack so much information into concise messages while being clear and consistent, but I hope at least this will give users seeing these messages enough context to infer what's going on, possibly with the help of our documentation. I intentionally didn't change which cases Terraform will return warnings or errors -- only the message texts -- although I did highlight in a comment in one of the tests that what it is a asserting seems a bit suspicious to me. I don't intend to address that here; instead, I intend that note to be something to refer to if we later see a bug report that calls that behavior into question. This does actually silence some _unrelated_ warnings and errors in cases where a provider block has an invalid provider local name as its label, because our other functions for dealing with provider addresses are written to panic if given invalid addresses under the assumption that earlier code will have guarded against that. Doing this allowed for the provider configuration validation logic to safely include more information about the configuration as helpful context, without risking tripping over known-invalid configuration and panicking in the process.	4 years ago
Kyle Davies	0ea6874bc1	Change aws.dest to aws.dst Documentation is wrong the `configuration_aliases` should be `[ aws.src, aws.dst ]` not `[ aws.src, aws.dest ]`.	4 years ago
savage-tm	d6a98ac22b	Document logical operators not short-circuiting Including a note about logical operators not short-circuiting will make the documentation clearer and more useful. https://github.com/hashicorp/terraform/issues/24128 includes examples of people being caught out by this lack of clarity.	4 years ago
James Bardin	e543dda043	Merge pull request #30629 from hashicorp/jbardin/data-read-hook ensure UI hooks are called for data sources	4 years ago
James Bardin	05a10f06d1	remove PreDiff and PostDiff hook calls PreDiff and PostDiff hooks were designed to be called immediately before and after the PlanResourceChange calls to the provider. Probably due to the confusing legacy naming of the hooks, these were scattered about the nodes involved with planning, causing the hooks to be called in a number of places where they were designed, including data sources and destroy plans. Since these hooks are not used at all any longer anyway, we can removed the extra calls with no effect. If we choose in the future to call PlanResourceChange for resource destroy plans, the hooks can be re-inserted (even though they currently are unused) into the new code path which must diverge from the current combined path of managed and data sources.	4 years ago
James Bardin	dc668dff38	ensure UI hooks are called for data sources The UI hooks for data source reads were missed during planning. Move the hook calls to immediatley before and after the ReadDataSource calls to ensure they are called during both plan and apply.	4 years ago
Alisdair McDiarmid	e75bcdc016	Update CHANGELOG.md	4 years ago
Alisdair McDiarmid	32f9fa9aac	Merge pull request #30613 from hashicorp/alisdair/check-rule-error-message-expressions core: Check rule error message expressions	4 years ago
Alisdair McDiarmid	f21d0e8bf6	website: Update docs for check rule error messages	4 years ago
Alisdair McDiarmid	45d0c04707	core: Add fallback for JSON syntax error messages Custom variable validations specified using JSON syntax would always parse error messages as string literals, even if they included template expressions. We need to be as backwards compatible with this behaviour as possible, which results in this complex fallback logic. More detail about this in the extensive code comments.	4 years ago
Alisdair McDiarmid	b59bffada6	core: Evaluate pre/postconditions during validate During the validation walk, we attempt to proactively evaluate check rule condition and error message expressions. This will help catch some errors as early as possible. At present, resource values in the validation walk are of dynamic type. This means that any references to resources will cause validation to be delayed, rather than presenting useful errors. Validation may still catch other errors, and any future changes which cause better type propagation will result in better validation too.	4 years ago
Alisdair McDiarmid	b06fe04621	core: Check rule error message expressions Error messages for preconditions, postconditions, and custom variable validations have until now been string literals. This commit changes this to treat the field as an HCL expression, which must evaluate to a string. Most commonly this will either be a string literal or a template expression. When the check rule condition is evaluated, we also evaluate the error message. This means that the error message should always evaluate to a string value, even if the condition passes. If it does not, this will result in an error diagnostic. If the condition fails, and the error message also fails to evaluate, we fall back to a default error message. This means that the check rule failure will still be reported, alongside diagnostics explaining why the custom error message failed to render. As part of this change, we also necessarily remove the heuristic about the error message format. This guidance can be readded in future as part of a configuration hint system.	4 years ago
Barrett Clark	979ac3da44	Merge pull request #30602 from hashicorp/barrettclark/update-go-slug Cloud: Update go-slug for terraform.tfstate exclusion	4 years ago
Barrett Clark	ecf76add75	Update go-slug for terraform.tfstate exclusion `go-slug` has been updated to not upload `terraform.tfstate` to the slug so that a user will no longer receive the error message about the leftover state file after migrating from the local backend to TFC.	4 years ago
Alisdair McDiarmid	92747e3459	Merge pull request #30575 from hashicorp/alisdair/upgrade-deps build: Upgrade `alibaba-cloud-sdk-go` and `winrmtest` dependencies	4 years ago
Alisdair McDiarmid	fe6ce539fa	go get github.com/dylanmei/winrmtest	4 years ago
Alisdair McDiarmid	51a08c79a4	go get github.com/aliyun/alibaba-cloud-sdk-go/sdk	4 years ago
Sebastian Rivera	dc63fda44b	Update CHANGELOG.md	4 years ago
Sebastian Rivera	afb956d745	Merge pull request #30141 from hashicorp/preapply-runtasks-clioutput Cloud run tasks (post-plan only) CLI integration	4 years ago
Sebastian Rivera	52c5f9f6b7	Updated for latest go-tfe run task changes	4 years ago
Laura Pacilio	e8364b2505	Merge pull request #30580 from hashicorp/fix-broken-link Fix broken link on provisioners connection page	4 years ago
Laura Pacilio	ad1ba5ef12	fix broken link on provisioners connection page	4 years ago
Craig Wright	195adc042a	Merge pull request #30574 from dhodun/doc_fix [Docs] Added github.com commit reference example	4 years ago
Sebastian Rivera	126d6df088	Added run task support for post plan run stage, removed pre apply This commit stems from the change to make post plan the default run task stage, at the time of this commit's writing! Since pre apply is under internal revision, we have removed the block that polls the pre apply stage until the team decides to re-add support for pre apply run tasks.	4 years ago
uturunku1	542e3f901d	run go mod tidy	4 years ago
uturunku1	383da4893b	use new enum string for task stages	4 years ago
uturunku1	e46683d2c7	pull latest changes from go-tfe run-tasks-integration branch	4 years ago
Brandon Croft	aa0dda81b4	Fall back to reading latest run without task_stages Older versions of TFE will not allow "task_stages" as an include parameter. In this case, fall back to reading the Run without additional options.	4 years ago
Brandon Croft	391b9c497c	update go-tfe go-tfe is pinned to branch run-tasks-integration pending API changes until run tasks support in the CLI is closer to release	4 years ago
uturunku1	46aaaa0a95	run go mod tidy	4 years ago
uturunku1	a9da859ee5	rename variables to something more descriptive	4 years ago
uturunku1	385589e1a4	run go mod tidy	4 years ago
uturunku1	77946af472	pull latest changes from go-tfe branch and use use new field name that previously was incorrectly named TaskStage	4 years ago
uturunku1	8090b23db7	delete unused function	4 years ago
Brandon Croft	0b8bb29a61	[cloud] refactor integration context and add code documentation	4 years ago
Brandon Croft	791c36c504	[cloud] report run tasks by name instead of assuming pre_apply	4 years ago
uturunku1	6b5da4d43c	[cloud] run tasks output formatting	4 years ago

1 2 3 4 5 ...

29595 Commits (b5cfc0bb8bc4f9f4ffca495a80d167bc0da02f97) All Branches Search

29595 Commits (b5cfc0bb8bc4f9f4ffca495a80d167bc0da02f97)

All Branches