Circular dependency between lambda alias, alarm and deployment group on upgrade 0.24 -> 0.28

[BDQ]

Hi All,
I'm attempting an upgrade from 0.24.1 => 0.28.0 and my lambda + deployment group code (summarized below) is now resulting in a circular dependency between the Lambda alias, the metric and the deployment group.

@sam-goodwin commented on a related issue here: https://github.com/awslabs/aws-cdk/pull/1628/files#r252155211

My code follows the docs example pretty closely, so I suspect the readme is now invalid.

  const graphqlLambda = new lambda.Function(stack, "graphql", {
    ...props.lambdaConfig,
    code: lambda.Code.asset("../src/handlers/main")
  });

  const version = graphqlLambda.addVersion(props.deploymentVersion);
  const graphQLAlias = new lambda.Alias(stack, "alias", {
    aliasName: "active",
    version
  });

  const application = new codedeploy.LambdaApplication(stack, "cdApp", {
    applicationName: stack.stackName
  });

  // deployment group
  const deploymentGroup = new codedeploy.LambdaDeploymentGroup(
    stack,
    "CanaryDeploys",
    {
      application,
      alias: graphQLAlias,
      deploymentConfig: props.isProd
        ? codedeploy.LambdaDeploymentConfig.Canary10Percent5Minutes
        : codedeploy.LambdaDeploymentConfig.AllAtOnce,
      alarms: []
    }
  );

  // this alarm will fail back the deploy if lambda starts generating errors
  deploymentGroup.addAlarm(
    new cloudwatch.Alarm(stack, "graphql-errs", {
      comparisonOperator: cloudwatch.ComparisonOperator.GreaterThanThreshold,
      threshold: 1,
      evaluationPeriods: 2,
      metric: graphQLAlias.metricErrors({ periodSec: 60 })
    })
  );

[sam-goodwin]

This is caused by #2091 - we fixed the aliasArn to properly !Ref the alias resource so that CFN models the implicit dependency. A consequence of this is now we have a circular dependency because CodeDeploy models Lambda deployments in a circular way:

• The alias's update policy references the deployment group
• The deployment group references the alias's ARN via the alarm's metric

We can fix this by having the alias's metrics construct the aliasArn from the underlying functionArn and the hard-coded aliasName.

[BDQ]

@sam-goodwin awesome, I really appreciate the quick response. The CDK team is the best!