-
Notifications
You must be signed in to change notification settings - Fork 150
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
Fix "resource that supports" to accommodate "after_unknown" values #445
Conversation
Note: This function may be extended to capture 'after' values as well. That would require flattening the multi level | ||
dictionaries in resource | ||
''' | ||
def remember_after_unknown(self, resource, after_unknown): |
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.
unit tests please :)
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.
Added a couple :)
|
||
# if resource doesn't have type field, try to extract it from address | ||
if not resource_type and 'address' in resource and resource['address']: | ||
resource_type = resource.get('address').split('.')[0] |
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.
What if this is a module ?
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.
True, then we would most likely need to use resource.get('address').split('.')[2]
in that case.
However, I'm inclined to delete this clause all together. Is it possible to not have type
in resource at first place?
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.
Not sure, I think that depends on the provider really.
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 made the change. However, we might run into a similar issue with the resource's address convention if provider doesn't add the type of the resource to the plan.
Might want to add the feature file to the test dir? :) |
Haha yes, I agree with @sleightsec here :) |
5763a46
to
7d7e8d6
Compare
Fixed an issue where the omission of
after_unknown
values were breaking the Given stepresource that supports
.Addresses #438, #441
Please note, in this setup the regular Given works well:
using
Given I have aws_rds_cluster defined
with the other two steps:Also note that kms_key_id is going to be an after_unknown value if and only if kms_key_id has a bad value (e.g. null)
So the
Given I have resource that supports kms_key_id defined
step is the culprit of this bug, as opposed to the omission ofafter_unknown
values