Deployment Lambda Hooks

[eladb]

It should not be too hard to add support for executing a lambda function pre/post deployment of CDK apps. Basically, a custom resource with a changing logical ID that only reacts to "CREATE" and automatically takes a dependency on everything (or everything takes a dependency on it)

This can be used, for example, to implement "live" integration tests where you deploy a stack and then asserts some things against it at the end of the deployment. If your assertions fail, the stack is rolled backed.

[dnagir]

Another use case in support of this - using AWS CLI to manage the resources that are not supported by CloudFormation (one such example is Cognito client integration OAuth details).

It would be great to be able to say something like this in terms of the API:

        new hooks.Function(this, `updateCognitoClient`, {
            runtime: l.Runtime.NodeJS810,
            code: l.Code.directory('functions'),
            handler: 'updateCognitoClient.handler'
        });

It would be great if this was designed well in conjunction with client-side hooks/events to have a coherent and easy to use API.

[eladb]

@dnagir you should look into Custom Resources for this use case and also aws/aws-cdk#1897

[rob-gonz]

Use Case in support of this:

After each stack is deployed/destroyed the CloudFormation output of the completed stack is provided to the lambda function called by the hook. In my particular use, I would like to be able to output the name of the staging environment, ELB/ALB endpoints, and URL's to be created. With that information, I can leverage Cloudflare/Godaddy/name.com API's to create CNAME records for new environments or update existing.

In general, this would really be useful to automate things further and make it much easier to have fully disposable environments.

[btotharye]

Another example external Atlas Mongo VPC peering that is created from the Mongo end and then accepted from the AWS side, I already have mongo code working but obviously now this has to be a custom resource instead of just being able to run conditionals in my code whether a deploy or destroy was ran.

Also it appears custom resources are expecting SDK calls not external code or 3rd party api calls like I am doing.

I guess we are forced into creating custom resources for this but that kinda defeats the purpose of having re-usable code and other external packages I've written that I would like to use.

[shurmanidze]

Use case: I'd like to seed a DB with some initial data on stack deployment complete.

[agalazis]

haha! @shurmanidze exactly my case

[binarythinktank]

Love this, some usecases that i would use it for:

1. I would like to create a codecommit repo, deploy it, get the information then automatically add the local git to it (add origin)

2. i would like to do similar for git submodules (on each of my lambda and s3 gui sources in the project)

3. add some initial data to databases and an initial user to cognito

4. create and deploy a config file to s3 gui (currently doing it with a custom resource)

5. a bunch of other stuff through api calls (cdn invalidation, domain management, etc.)

[agalazis]

also consider fargate hooks since database restore might hit some lambda limitations. eg.spin a fargate task (from an ecr image for example) and exit

[eladb]

Duplicate #46