Commit Graph

29587 Commits

Author SHA1 Message Date
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.
2022-03-11 10:20:50 -05:00
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.
2022-03-11 10:20:50 -05:00
Laura Pacilio 821064edd3
Merge pull request #30637 from kderck/patch-2
Change aws.dest to aws.dst
2022-03-10 18:08:29 -05:00
Laura Pacilio 63fa72022f
Merge pull request #30631 from savage-tm/patch-1
Document logical operators not short-circuiting
2022-03-10 18:03:47 -05:00
Martin Atkins 2aa1613c19
Update CHANGELOG.md 2022-03-10 10:07:33 -08:00
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.
2022-03-10 10:05:56 -08:00
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 ]`.
2022-03-09 20:26:10 +00:00
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.
2022-03-09 17:10:06 +13:00
James Bardin e543dda043
Merge pull request #30629 from hashicorp/jbardin/data-read-hook
ensure UI hooks are called for data sources
2022-03-08 15:24:21 -05:00
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.
2022-03-08 13:48:41 -05:00
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.
2022-03-08 13:06:30 -05:00
Alisdair McDiarmid e75bcdc016
Update CHANGELOG.md 2022-03-07 12:12:28 -05:00
Alisdair McDiarmid 32f9fa9aac
Merge pull request #30613 from hashicorp/alisdair/check-rule-error-message-expressions
core: Check rule error message expressions
2022-03-07 12:10:49 -05:00
Alisdair McDiarmid f21d0e8bf6 website: Update docs for check rule error messages 2022-03-04 15:39:31 -05:00
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.
2022-03-04 15:39:31 -05:00
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.
2022-03-04 15:39:31 -05:00
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.
2022-03-04 15:35:39 -05:00
Barrett Clark 979ac3da44
Merge pull request #30602 from hashicorp/barrettclark/update-go-slug
Cloud: Update go-slug for terraform.tfstate exclusion
2022-03-02 11:02:23 -06:00
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.
2022-03-02 10:12:18 -06:00
Alisdair McDiarmid 92747e3459
Merge pull request #30575 from hashicorp/alisdair/upgrade-deps
build: Upgrade `alibaba-cloud-sdk-go` and `winrmtest` dependencies
2022-03-01 17:02:29 -05:00
Alisdair McDiarmid fe6ce539fa go get github.com/dylanmei/winrmtest 2022-03-01 16:52:48 -05:00
Alisdair McDiarmid 51a08c79a4 go get github.com/aliyun/alibaba-cloud-sdk-go/sdk 2022-03-01 16:52:17 -05:00
Sebastian Rivera dc63fda44b Update CHANGELOG.md 2022-02-25 14:34:10 -08:00
Sebastian Rivera afb956d745
Merge pull request #30141 from hashicorp/preapply-runtasks-clioutput
Cloud run tasks (post-plan only) CLI integration
2022-02-25 15:46:46 -05:00
Sebastian Rivera 52c5f9f6b7 Updated for latest go-tfe run task changes 2022-02-25 15:32:16 -05:00
Laura Pacilio e8364b2505
Merge pull request #30580 from hashicorp/fix-broken-link
Fix broken link on provisioners connection page
2022-02-25 11:25:27 -05:00
Laura Pacilio ad1ba5ef12 fix broken link on provisioners connection page 2022-02-24 18:15:05 -05:00
Craig Wright 195adc042a
Merge pull request #30574 from dhodun/doc_fix
[Docs] Added github.com commit reference example
2022-02-24 12:08:17 -08:00
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.
2022-02-24 14:06:57 -05:00
uturunku1 542e3f901d run go mod tidy 2022-02-24 14:06:57 -05:00
uturunku1 383da4893b use new enum string for task stages 2022-02-24 14:06:57 -05:00
uturunku1 e46683d2c7 pull latest changes from go-tfe run-tasks-integration branch 2022-02-24 14:06:57 -05:00
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.
2022-02-24 14:06:57 -05:00
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
2022-02-24 14:06:55 -05:00
uturunku1 46aaaa0a95 run go mod tidy 2022-02-24 14:03:27 -05:00
uturunku1 a9da859ee5 rename variables to something more descriptive 2022-02-24 14:03:02 -05:00
uturunku1 385589e1a4 run go mod tidy 2022-02-24 14:03:02 -05:00
uturunku1 77946af472 pull latest changes from go-tfe branch and use use new field name that previously was incorrectly named TaskStage 2022-02-24 14:03:00 -05:00
uturunku1 8090b23db7 delete unused function 2022-02-24 14:02:37 -05:00
Brandon Croft 0b8bb29a61 [cloud] refactor integration context and add code documentation 2022-02-24 14:02:37 -05:00
Brandon Croft 791c36c504 [cloud] report run tasks by name instead of assuming pre_apply 2022-02-24 14:02:37 -05:00
uturunku1 6b5da4d43c [cloud] run tasks output formatting 2022-02-24 14:02:37 -05:00
Brandon Croft 2938ec43fa [cloud] handle unreachable run tasks 2022-02-24 14:02:37 -05:00
uturunku1 3e9ae69a12 [cloud] run tasks integration
This change will await the completion of pre-apply run tasks if they
exist on a run and then report the results.

It also adds an abstraction when interacting with cloud integrations such
as policy checking and cost estimation that simplify and unify output,
although I did not go so far as to refactor those callers to use it yet.
2022-02-24 14:02:35 -05:00
kmoe 2393c48720
Update CHANGELOG.md 2022-02-23 11:59:01 +00:00
Alisdair McDiarmid 70db495d00
Merge pull request #30525 from nozaq/provider-config-default
jsonconfig: fix keys for default providers
2022-02-22 16:13:41 -05:00
Drew Hodun a26b551d47 added github.com commit reference example 2022-02-22 11:09:22 -05:00
Alisdair McDiarmid 17492285f4
Merge pull request #30561 from hashicorp/alisdair/json-output-optimization
jsonplan: Improve performance for deep objects
2022-02-22 10:12:00 -05:00
Alisdair McDiarmid 3e4d6b252f jsonplan: Improve performance for deep objects
When calculating the unknown values for JSON plan output, we would
previously recursively call the `unknownAsBool` function on the current
sub-tree twice, if any values were unknown. This was wasteful, but not
noticeable for normal Terraform resource shapes.

However for deeper nested object values, such as Kubernetes manifests,
this was a severe performance problem, causing `terraform show -json` to
take several hours to render a plan.

This commit reuses the already calculated unknown value for the subtree,
and adds benchmark coverage to demonstrate the improvement.
2022-02-18 17:00:18 -05:00
nozaq 3c32f7a56c
jsonconfig: add implicitly created provider configs 2022-02-19 01:55:09 +09:00