Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

terraform: Eval module call arguments for import #25890

Merged
merged 1 commit into from
Aug 19, 2020
Merged

Conversation

alisdair
Copy link
Contributor

Include the import walk in the list of operations for which we create an EvalModuleCallArgument node. This causes module call arguments to be evaluated even if the module variables have defaults, ensuring that invalid default values (such as the common {} for variables thought of as maps) do not cause failures specific to import.

This fixes a bug where a child module evaluates an input variable in its locals block, assuming that it is a nested object structure. The bug report includes a default value of {}, which is overridden by a root variable value. Without the eval node added in this commit, the default value is used and the local evaluation errors.

Note: I'm surprised that we weren't evaluating module call arguments for imports, as that seems like it would break import for module expansion in many cases. Is this intentional, and will this change therefore break something else?

Fixes #25888; see reproduction here.

Include the import walk in the list of operations for which we create an
EvalModuleCallArgument node. This causes module call arguments to be
evaluated even if the module variables have defaults, ensuring that
invalid default values (such as the common "{}" for variables thought of
as maps) do not cause failures specific to import.

This fixes a bug where a child module evaluates an input variable in its
locals block, assuming that it is a nested object structure. The bug
report includes a default value of "{}", which is overridden by a root
variable value. Without the eval node added in this commit, the default
value is used and the local evaluation errors.
@alisdair alisdair added the import Importing resources label Aug 17, 2020
@alisdair alisdair self-assigned this Aug 17, 2020
@codecov
Copy link

codecov bot commented Aug 17, 2020

Codecov Report

Merging #25890 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted Files Coverage Δ
terraform/node_module_variable.go 78.31% <100.00%> (ø)
terraform/node_resource_plan.go 93.44% <0.00%> (+1.63%) ⬆️

Copy link
Contributor

@mildwonkey mildwonkey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, and import (MY NEMESIS!!!) being broken kind of feels like its default state, so while we should make sure this doesn't make @jbardin twitch I don't see any cause for concern with this change.

Absolutely perfect and wonderfully helpful test commentary, thank you muchly for that!

@ghost
Copy link

ghost commented Oct 11, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked as resolved and limited conversation to collaborators Oct 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
import Importing resources
Projects
None yet
Development

Successfully merging this pull request may close these issues.

unexpected "Error: Unsupported attribute" for type "any" variable import (0.12.29/0.13.0)
3 participants