serverless: Show all errors from cloudformation in CLI on stack update failure

@serverless/team Making some progress. What do you think about the output so far?

I’m going with --verbose quite common amongst CLI’s, thanks for pointing this out @ac360!

Regarding the actual output I will go with Cloudformation - 👍

We could fetch for new stack events every x seconds and break if any of the following states are noticed:

sucessStates = [
  "CREATE_COMPLETE",
  "UPDATE_COMPLETE"
]

failureStates = [
  "CREATE_FAILED",
  "DELETE_FAILED",
  "ROLLBACK_COMPLETE",
  "ROLLBACK_FAILED",
  "UPDATE_ROLLBACK_COMPLETE",
  "UPDATE_ROLLBACK_FAILED"
]

@flomotlik I would be willing to take on this task. Let me know if it’s oke 👍

Can’t we just tail the CloudFormation deployment events during the deployment? With some nice chalk colors like the AWS CloudFormation console shows it for CREATE_IN_PROGRESS, UPDATE_IN_PROGRESS, DELETE_IN_PROGRESS, etc. Would totally skip the need to have the AWS console open.

I’ve run into this problem as well, many times… On my first deployment and lots of subsequent deployments. Additionally, I often get an undefined message too.

IMO, this is a big priority. It’s currently killing the core development experience. Fortunately, this doesn’t seem hard to fix.

Proposal:

• On failed deployment, call CloudFormation describeStackEvents via SDK.
• Loop through those events and collect ones that have a failed status.
• Either list all of the resources with a failed status and their reason OR list only the original one that failed, since others that fail after the first failed resource typically have the same error message.

If we can decide on the overall proposal, I bet someone in the community could knock this out in a few hours, if not myself because implementing it is probably faster than continuing to go to the AWS Console to uncover the real error 😛

+1 to @mthenw’s comment, with one design nitpik to consistently use hyphens instead of colons. Not a big deal, but colons seem to be used heavily in the CF resource names, and don’t want to add confusion. +1 to @flomotlik’s comment that we hide CF events by default (as long as we print out the full CF error at the end). I recommend the common --verbose flag. And trimming/refining the printed statements by Serverless so that they inform the user that CloudFormation is what’s being used.

Examples:

sls deploy --verbose

Updating CloudFormation stack and reporting progress...
CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - hello
CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - hello2
CloudFormation - UPDATE_FAILED - AWS::Lambda::Function - hello2

   Serverless Error -------------------------------------
      An error occurred during deployment in CloudFormation:  [full error message]

sls deploy

Updating CloudFormation stack and reporting progress...

   Serverless Error -------------------------------------
      An error occurred during deployment in CloudFormation:  [full error message]

Done. This looks amazing. I want to use it instantly ☺️

Okidoki, I will start working on it and hopefully have something by the beginning of next week.