-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
interpolate: Interpolate computed list attributes #2157
interpolate: Interpolate computed list attributes #2157
Conversation
85fe60d
to
5651430
Compare
5651430
to
025619a
Compare
On a preliminary scan this looks good to me. I'm going to keep scanning to look for anything... but if the rest of the unit tests pass its a pretty good sign. @phinze can you take a look too? I'd feel better if you checked off on this as well. |
@radeksimko this is looking great so far! This implementation applies to all three of |
}) | ||
// Zero + zero elements | ||
testInterpolate(t, i, scope, "aws_route53_zone.terra.*.nothing", ast.Variable{ | ||
Value: config.InterpSplitDelim, // Not sure if this is desired behaviour? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm yeah I guess I'd expect an empty list here, but a single InterpSplitDelim
indicates ["", ""]
right? Another valid return here would be a list of two empty lists [[], []]
, but we're "flattening" the two sub-lists already it seems like []
is what we should shoot for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was personally tempted to make it a single empty list as well, but considering the debate in here #1495 (comment) I realise some people may consider that to be way too magic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's worth rabbit holing too much on this, so I'm ultimately fine with it either way, but my vote would still be for a single list, since our "string-hack" lists don't allow for nesting right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point, I just need to find out how to express an empty list via our "string-hack".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just need to find out how to express an empty list via our "string-hack".
I've got an idea on that - related to fix for #2240 - finishing up a PR now and I'll highlight you.
025619a
to
33a0611
Compare
I reckon this is the related PR: #2504 which should make representation of empty list possible. |
@radeksimko yep! finally 😀 If you rebase on top of that and use the |
Hey @radeksimko, Do you plan on updating to StringList? I am trying to render the route53.nameservers list as in your example ... |
@zollie Thanks for pinging me, I was a bit busy with other things, but I do plan to update it fairly soon. The change may not make it to I should have some time this week - can't be more specific now, sorry. |
Cool...thanks! Looking forward to it. |
df070d2
to
5eea388
Compare
All refactoring finished. @phinze to your question:
It applies to I have also added a couple of tests for the |
a3dda6d
to
46b9dce
Compare
46b9dce
to
6a4caef
Compare
6a4caef
to
fe41299
Compare
fe41299
to
91d750d
Compare
Thanks to @radeksimko for reminding me about this one. LGTM - landing, which I believe should fix #2795! |
interpolate: Interpolate computed list attributes
p.s. great work on this, @radeksimko! 😀 |
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs #2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs #2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs #2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs #2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs hashicorp#2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
References to computed list-ish attributes (set, list, map) were being improperly resolved as an empty list `[]` during the plan phase (when the value of the reference is not yet known) instead of as an UnknownValue. A "diffs didn't match" failure in an AWS DirectoryServices test led to this discovery (and this commit fixes the failing test): https://travis-ci.org/hashicorp/terraform/jobs/104812951 Refs hashicorp#2157 which has the original work to support computed list attributes at all. This is just a simple tweak to that work. /cc @radeksimko
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. |
This will solve issues with all list attributes that are computed and currently can't be actually used as lists (i.e. we can't use built-in functions like
join()
).The current output coming from
valueResourceVar
isconfig.UnknownVariableValue
since it's looking forresource.attribute
whereas it's present asresource.attribute.#
+resource.attribute.0
+resource.attribute.1
etc. in the givenmap
.Status:
count
count
count
count
Related: #1999
Test plan
TypeList
TypeMap
TypeSet
Impact