AutoPublishAlias: Support updating version when things other than CodeUri Changes

[rmmeans]

Description:

Per the documentation, AutoPublishAlias only supports publishing another function version when the CodeUri changes. While having AutoPublishAlias in its current state is still beneficial, I have found this has caused much confusion and even bugs that took quite some time to track down. Specifically, when things such as environment variables are changed on the stack.

The "gotcha" that occurs is because an environment variable might be passed as a stack parameter (for instance). When doing a stack update and updating the parameter, everything appears to execute cleanly. The stack change set picks up that the function needs to be updated, etc and the update is marked as successful. This causes the false belief that your update got applied successfully, only on close inspection of the lambda function do you discover that the lambda function was updated, but a new version was not tied to the alias.

I am curious if there is plans to remove this limitation? While the documentation does spell this out clearly, unless someone updating the stack knows that function(s) in the stack are using the AutoPublishAlias feature and knows about this caveat - they they might think an update was successful with no other action needed.

[digioak-zz]

Appears to be a bug in how we process AutoPublishAlias. We're going to look deeper into a potential solution.

[nick-romano0]

Just wanted to bump this, it's been an issue for us as well. Our issue is when changing memory allocations.

[brettstack]

This is similar to https://github.com/awslabs/serverless-application-model/issues/479 for APIs only deploying when the Swagger changes. We do have a proposal for APIs to always deploy even when we can't detect a change https://github.com/awslabs/serverless-application-model/issues/660. However, I believe that Lambda won't allow you to create a new version of a Function if there have been no changes at all, making this solution not viable in this case.

We could detect changes to the entire Function configuration itself, however, we don't currently transform anything based on Parameter values which we would need to do to cover this issue completely.

[lanefelker]

Any updates on this? Is there a solution to make a new lambda version created by environment variable change be tied to the alias?

[chris-malley-alertme]

Also an issue for us; we use an environment variable to change log level and should to be able to update this without rebuilding the code.

[nwb-ilan]

I don't understand the use for AutoPublishAlias if it doesn't support configuration changes such as env variable.
~~The workaround that comes to mind is to aws lambda update-alias on all the functions in the stack to the '$latest' version after every sam deploy, but that defeats the purpose of having AutoPublishAlias.~~
Seems like using '$latest' as one of the alias routes is not an option, so that leaves the option of aws lambda publish-version and then aws lambda update-alias, defeating the purpose of AutoPublishAlias Am I missing something?

[keetonian]

Similar to #1305 for environment variables. This would be good to support, look at #1305 at how to implement this change.

[driverpt]

Any updates on this one?

[hoffa]

Adding AWS::LanguageExtensions to the Transform can help in some situations (specifically when the property is supported by AutoPublishAlias and uses intrinsic functions), see #2533.

[hoffa]

Relaying from #2418:

There's been a few similar requests (e.g. #413). We can't update the most straightforward way as it would be a backward incompatible change (would cause many redeployments).

We could however consider an opt-in approach. Something like this (just rough idea):

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Timeout: 10
    AutoPublishAlias: live
    AutoPublishAdditionalProperties:
      - Timeout
    ...

[aaythapa]

Closing this, the fix will be released over the coming weeks