serverless-application-model: AutoPublishAlias not working in cloudformation

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;
};

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.

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

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (5 by maintainers)

Most upvoted comments

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

Code has been updated at the same CodeUri
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.

whereisaaron on Jul 21, 2019

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.

jmnarloch on Mar 9, 2020

@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 on Jun 30, 2020

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?

kangks on Jul 5, 2019