Serverless-application-model: AutoPublishAlias not working in cloudformation

[Private-SO]

This is an issue.

Steps to Reproduce

Below are the lambda functions.

markleV1

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Hades!'),
    };
    return response;
};

markleV2

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Zeus!'),
    };
    return response;
};

1) Deploy the below cloudformation template

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Transform": "AWS::Serverless-2016-10-31",
  "Description": "AWS CloudFormation sample template that contains a single Lambda function behind an API Gateway",

  "Resources": {

      "MyLambdaFunction": {
        "Type": "AWS::Serverless::Function",
        "Properties": {
    "Handler": "markle.js",
    "Runtime": "nodejs8.10",
    "CodeUri": "s3://my-bucket-name/markleV1.zip",
    "AutoPublishAlias": "live",
    "Description": "Creates thumbnails of uploaded images",
    "MemorySize": 1024,
    "Timeout": 15,
    "Policies": [
        "AWSLambdaExecute"
    ]
 }
}
},

  "Outputs": {
    "Version": {
      "Description": "Version ARN",
      "Value": { "Ref" : "MyLambdaFunction.Version" }
    }
  }
}

After deploying the above template i can see that it had produced an alias,version and lambda function.

2) Here i had changed the codeuri of the above template to like this
"CodeUri": "s3://dynamodbputtest/markleV2.zip" and updated the stack. As said in the documentation since there is an change in the codeuri it need to publish a new version and assign alias to the new version. But i didnt see any new version .

Am i missing anything?
Any help is appreicated
Thanks

[keetonian]

Did your stack update complete successfully?

I just created a stack with AutoPublishAlias: live and verified that the alias was created correctly and pointed to the published version of the function. I then updated my function and deployed to the stack again, which caused a new version to be created and the live alias was successfully updated to point to that new version.

I could see which version my alias was pointing at by going to the lambda function in the console, clicking "Qualifiers", and verifying that the alias pointed at the latest version (for me, version 2 of my function).

[Private-SO]

Thanks @keetonian .

Yeah my stack updated successfully but didnt created new version. You are saying ihad updated the function and deployed to the stack , Did you tried with my above configuration ?

Because the above configuration didnt worked for me .
Thanks

[keetonian]

Ok, I'll try the exact steps you recorded. Did you update the stack with aws cloudformation deploy or how did you update the stack?

[Private-SO]

No i didn't tried it with aws cloudformation deploy , i deployed using cloudformation console.

[yuminghub]

I believe AutoPublishAlias is a SAM feature instead of it's cloudformation superset.
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html

I have my project function configure as below, which is perfectly fine, just fyr.

    ProfilePostFunction:
      Type: "AWS::Serverless::Function"
      Properties:
        Handler: index.handler
        Runtime: nodejs8.10
        FunctionName: !Join ["", [ !Ref EnvrType ,"-", "SI-post-profile-image" ] ]
        Role: 'arn:aws:iam::45645654645645:role/aiportal-lambda-execution-role'
        CodeUri: lambdas/SI-post-profile-image
        AutoPublishAlias: dev
        DeploymentPreference:
          Type: AllAtOnce
          Alarms:
            # A list of alarms that you want to monitor
            - !Ref AliasErrorMetricGreaterThanZeroAlarm
            - !Ref LatestVersionErrorMetricGreaterThanZeroAlarm

[jlhood]

SAM templates can be deployed via CloudFormation (Console or CLI). Remaining action item for @keetonian is to try to reproduce via the CloudFormation console.

@Private-SO One thing to note, you are using AutoPublishAlias without DeploymentPreference. Is that intentional? The two are usually used together.

[Private-SO]

@jlhood , Yes my usecase don't need DeploymentPreference. Thats the reason i skipped that.

[keetonian]

@Private-SO I followed the exact steps that you posted in your original post. You are correct in that a new version is not created when following those steps.

The reason for this is that, when you update the stack in the CloudFormation console, the original SAM template is not used; rather, the transformed CloudFormation template is used. This means that SAM does not run and is not able to change the Function Version resource for you so that the stack deploys a new version.

I can recommend two ways to make this work as expected:

1. If you want to use the designer in the console, if you redeploy a template with a Function Version in it, make a change to the Logical Id of the function version resource and make sure to update the Alias and Outputs with this new logical id, as both of those reference the function version in your sample template.
2. Make changes to your original SAM template and redeploy the template to the same stack and it will make these changes to the Function Version resource for you.

[kangks]

If I am using nested stack for functions which are in S3, it is quite count productive to have to touch that nested stack.

Is there any way to force the root stack in SAM to reevaluate the nested stack for the function?

[whereisaaron]

AutoPublishAlias only publishes a new version of the Lambda function if the CodeUri changes. This means it fails to cover two common use cases:

1. Code has been updated at the same CodeUri
2. Environment variable values have changed, but code (and CodeUri) is unchanged.

Environment variable changes should also trigger publishing a new version. Plus we can use a dummy environment variable to trigger code updates from the same CodeUri, e.g. CODE_VERSION=1.2.3.

If you are using SAM, this deficiency of AutoPublishAlias means you basically need to pointlessly build, package and upload the code, just to change the environment variables. That defeats AWS's whole stated use case for environment variables.

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html

AutoPublishAlias: By adding this property and specifying an alias name, AWS SAM:

• Detects when new code is being deployed, based on changes to the Lambda function's Amazon S3 URI.
• Creates and publishes an updated version of that function with the latest code.

[pkspks]

I echo @whereisaaron 's thoughts. Our deployments are right now wrong as changing environment variables is not triggering publishing a new version and any subscription/api pointing to the lambda points to the wrong version.

EDIT:
More details:
We have stacks that embed SAM applications and pass parameters to it based on the environment/config.
SAM application template refers to parameters in function env variables. Function handles SQS events. SQS event subscription points to ":"
When the config changes, SAM app version does not change but the parameters passed to it changes. This causes lambda to be updated but a version to not be published and alias to continue pointing to older version with older env variables.

[jmnarloch]

Hey, the problem had been addressed in latest SAM version by allowing to configure the hash of published Lambda version through AutoPublishCodeSha256. So that you don't the version unless your code base has actually changed. This still requires you to modify your build step to include logic for computing the hash code.

[mokele]

@whereisaaron did you ever get a solution to this allowing just environment variables to be modified and triggering an update to the alias? This is a severe bug imo, going to have to go and route out whether there is an existing bug filed for it outside of this topic, since the original topic is slightly different (and closed). I've tested it out and the PreTraffic deployment hook successfully triggers giving you the opportunity (in the hook) to catch bugs introduced by env variable changes, but if no alias is updated then what's the point

outside the hack of using AutoPublishCodeSha256 is there another solution? – why it's named this way is rather confusing especially if it can be used as the hacky equivalent of something more akin to AuthPublishForceVersion which you can given any value. There is no limit to it needing to be a 256 has of anything, '1' is a valid value which we may have to go with and having to increment it every time we know we've only modified environment variables

[mokele]

The other related bug is here #413 :+1:

[kybrdbnd]

Hey, the problem had been addressed in latest SAM version by allowing to configure the hash of published Lambda version through AutoPublishCodeSha256. So that you don't the version unless your code base has actually changed. This still requires you to modify your build step to include logic for computing the hash code.

There is a bug, as mentioned in here -> https://github.com/aws/serverless-application-model/issues/1497, I am facing the same issue