Conversation
Test Results - Preflight, Unit22 298 tests +6 20 555 ✅ +6 15m 59s ⏱️ +25s Results for commit 812284b. ± Comparison against base commit 928f470. This pull request removes 1 and adds 7 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
Test Results - Alternative Providers578 tests - 772 330 ✅ - 371 25m 44s ⏱️ - 14m 22s Results for commit 812284b. ± Comparison against base commit 928f470. This pull request removes 775 and adds 3 tests. Note that renamed tests count towards both.This pull request removes 404 skipped tests and adds 3 skipped tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
Test Results (amd64) - Integration, Bootstrap 5 files ± 0 5 suites ±0 2h 40m 17s ⏱️ + 1m 44s Results for commit 812284b. ± Comparison against base commit 928f470. ♻️ This comment has been updated with latest results. |
| if s is False or s is True: | ||
| return False |
| parameters={"LogGroupName": log_group_name}, | ||
| ) | ||
|
|
||
| snapshot.match("failed-stack-describe", exc_info.value.describe_result) |
There was a problem hiding this comment.
Nit: It could be useful to have the status reason if there was any.
There was a problem hiding this comment.
Sorry I'm not sure I understand. There is no StatusReason in the snapshot so do you mean we should set it even though it's not in parity?
There was a problem hiding this comment.
No. I'm talking about the StatusReason that should be in the CREATE_FAILED event of the Log Group.
Motivation
A customer raised an issue with deploying their stack which contains a
NumberParameter type. Specifically they were using it in a condition:When supplied with the input
[{"ParameterKey": "Value", "ParameterValue": "1"}](all parameter values passed in are strings) the1was treated as a string, then compared to the integer1(i.e."1" == 1), which is falsy and as such the condition evaluates toFalse.Changes
TBD