Send the stack that a failed deployment created

[mnapoli]

Problem

A serverless.yml deployment only tells Bref Cloud its stack once it succeeds: the stack name and region come from serverless info, which the CLI runs after a successful serverless deploy.

When the first deployment of an environment fails in CloudFormation, the stack exists (usually in UPDATE_ROLLBACK_COMPLETE, with its deployment bucket), but Bref Cloud doesn't know about it. Removing the environment then leaves the stack and its bucket in the AWS account, with nothing in Bref Cloud pointing to them any more.

Change

When serverless deploy fails, the CLI looks in the osls output for the stack that this deployment created, and sends its name and region with the failed deployment. Bref Cloud already accepts and stores them for a failed deployment, so no change is needed there: removing the environment deletes the stack, as for an environment deployed successfully.

The CLI runs osls with --verbose, which logs the events of the stack. The first stack event is the stack's own:

• CREATE_IN_PROGRESS: osls created the stack, so this deployment created it. It is sent.
• UPDATE_IN_PROGRESS: the stack already existed, e.g. deployed with the Serverless Framework before moving to Bref Cloud. Nothing is sent, so removing the environment doesn't delete a stack that Bref Cloud didn't create.
• No stack event: the deployment failed before CloudFormation (e.g. an unresolved variable). There is no stack.

Also:

• The events of nested stacks come after the root stack's: a nested stack created during an update doesn't count.
• The name is the real one, also with provider.stackName.
• The region is the one osls prints in Deploying <service> to stage <stage> (<region>), also when serverless.yml doesn't set provider.region.
• The whole osls output is now kept in memory for this, because the pending logs are emptied every time they are pushed to Bref Cloud.

Tests

ServerlessFrameworkTest finds the stack in:

• the output of a first deployment that failed in CloudFormation (a real output, shortened),
• the output of an existing stack's update that creates a nested stack (nothing found),
• the output of a deployment that failed before CloudFormation (a real output, nothing found).

Bref Cloud

Bref Cloud already handles an environment that has a stack but no successful deployment: bref.php deployments record the stack name before CloudFormation runs. The environment page doesn't report the stack as missing until a deployment succeeds, and removing the environment empties the stack's buckets and deletes the stack (checked against a stack in UPDATE_ROLLBACK_COMPLETE with its deployment bucket).

Not tested end to end with this change, nor with osls@4 (same log lines according to its source). If the lines aren't found, nothing is sent, as before.