-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
CFn: fix invalid behaviour for nested intrinsic calls #13146
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
Conversation
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 35m 42s ⏱️ - 1h 19m 18s Results for commit 43c1fe6. ± Comparison against base commit f8e915e. This pull request removes 4098 and adds 1 tests. Note that renamed tests count towards both. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 47m 9s ⏱️ Results for commit 43c1fe6. |
Test Results - Alternative Providers571 tests 330 ✅ 24m 11s ⏱️ Results for commit 43c1fe6. |
Motivation
A previous PR #13136 broke template deployment in the Pro repsitory. The issue was that while visiting the template for CreateChangeSet in the transformer, we were not handling the case where the nested intrinsic function calls would not return
Nonebut would still return a semi-valid transformed value. In particular, the inner intrinsic would return the visited arguments (say["Resource", "Attribute"]from aGetAttcall. The arguments to select may be something like:This problem is really highlighting that we need a way of traversing the template, but returning a KNOWN sentinel value representing an unknown value. Let's tackle this in a follow up.
Changes
Fn::Selectargument handlingtransformvisit...get_attto better match the other overridesvalidatorvisit...get_attto replicate the structure of thetransformimplementation(?:[a-z0-9]+(?:[._-][a-z0-9]+)*/)*[a-z0-9]+(?:[._-][a-z0-9]+)*