When a stack with bad cloudformation has been created with disable_rollback=true, it completes with an expected state of CREATE_FAILED with no rollback of resources. If you run the same create stack action via stackup, you'd expect it to complete with CREATE_FAILED and no rollbacks.
However, through a sequence of events and function calls, the disable_rollback option has been removed from the original options parameter, thereby causing the second create stack action to fail and rollback.
Tests after code changes:
Ran create stack +disable_rollback=true using the same stack name multiple times, and ensured that a bad cloudformation template causes a CREATE_FAILED with no rollback of resources every time
Updated the spec tests to validate the scenario above
As per issue https://github.com/realestate-com-au/stackup/issues/64, the create and update stack functions are mutating the options parameter passed to it.
When a stack with bad cloudformation has been created with disable_rollback=true, it completes with an expected state of CREATE_FAILED with no rollback of resources. If you run the same create stack action via stackup, you'd expect it to complete with CREATE_FAILED and no rollbacks.
However, through a sequence of events and function calls, the disable_rollback option has been removed from the original options parameter, thereby causing the second create stack action to fail and rollback.
Tests after code changes: