Repository navigation
Lamba version not created despite using PublishLambdaVersion #3802
Description
Activity
I just tried moving the layers to example_api.yaml, and then it works as expected.
Is it still expected behavior that it does not work when defining the layers in the root stack?Hi @TobiasRDahl,
It sounds like the deployment of the root stack that contains your updated layers does not trigger new deployment of the nested stacks (contains Lambda functions). The next deployment of your nested stack of should trigger a function version to be published, during which the new function versions should refer the newer version of the layer.
Do you mind confirming that this is actually the case?
How do you build and deploy these stacks?Hi @TobiasRDahl,
It sounds like the deployment of the root stack that contains your updated layers does not trigger new deployment of the nested stacks (contains Lambda functions). The next deployment of your nested stack of should trigger a function version to be published, during which the new function versions should refer the newer version of the layer.
Do you mind confirming that this is actually the case? How do you build and deploy these stacks?
Hi @vicheey
Yes, that seems indeed to be the case.
We build and deploy from a Github Actions workflow:
- name: Deploy run: | echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin cd iac/ make deployMakefile:
SHELL := /bin/bash .PHONY: diff_cdf_template deploy deploy_serverless_dependencies init: @if [[ -z "${TEMPLATE_FILE}" || -z "${STACK_NAME}" || -z "${REGION}" || -z "${ENV}" ]]; then \ echo 'One or more variables are undefined!' ; \ exit 1; \ fi diff_cdf_template: init sam deploy \ --no-execute-changeset \ --no-fail-on-empty-changeset \ --stack-name ${STACK_NAME} \ --region ${REGION} \ --resolve-s3 \ --resolve-image-repos \ --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --parameter-overrides 'EnvPipeline=${ENV} \ AmmaBackendApiId=${AMMA_BACKEND_API_ID} \ AmmaFrontendApiId=${AMMA_FRONTEND_API_ID} \ AuroraMasterSecretArn=${RDS_MASTER_SECRET_ARN}' deploy: init sam build \ --debug \ --parallel \ --template-file ${TEMPLATE_FILE} && \ sam deploy \ --no-fail-on-empty-changeset \ --stack-name ${STACK_NAME} \ --region ${REGION} \ --resolve-s3 \ --resolve-image-repos \ --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --parameter-overrides 'EnvPipeline=${ENV} \ AmmaBackendApiId=${AMMA_BACKEND_API_ID} \ AmmaFrontendApiId=${AMMA_FRONTEND_API_ID} \ AuroraMasterSecretArn=${RDS_MASTER_SECRET_ARN}'Wondering if this was ever proven to be an issue or not?
We've just seen something similar today, updating a parameter passed to a
AWS::Serverless::Applicationresource, resulted in the nested stack being updated and all resource, including the$Latestversion of the lambda, being updated correctly BUT a lambda version was not created (and as a result the associated alias was not updated).The
AutoPublishAliasandAutoPublishAliasAllPropertiesare both correctly set, so slightly confused.Wondering if this was ever proven to be an issue or not?
We've just seen something similar today, updating a parameter passed to a
AWS::Serverless::Applicationresource, resulted in the nested stack being updated and all resource, including the$Latestversion of the lambda, being updated correctly BUT a lambda version was not created (and as a result the associated alias was not updated).The
AutoPublishAliasandAutoPublishAliasAllPropertiesare both correctly set, so slightly confused.@chrisclayson - it sounds like your case is a bit different. My issue was related to layers stored in the root stack. I worked around that issue by moving and duplicating the layers in each nested stack.
Description
I am trying to implement SnapStart on two of my lambdas. It works well, until we deployed with only changes in the layers - then a new lambda version was not created.
I came across the possibility to set PublishLambdaVersion = true on the AWS::Serverless::LayerVersion resource.
The bug is that a new lambda version is not created, despite the layer version being bumped up.
In our rootstack we have two layers defined which are used by several nested stacks.
It is only 2 out of many lambdas in which we want to use SnapStart and thereby have the need for new lambda versions being created when a layer is updated.
Steps to reproduce
Rootstack:
We then have several nested stacks defined in the rootstack, fx:
Inside example_api.yaml, we have the lambda defined:
I first deployed the stack with the above configuration.
I then made a simple change in the RdsSchemaLayer and deployed again.
Observed result
I observe that the RdsSchemaLayer has version 624
On the lambda, no new version is created:
Version 37 (latest lambda version) is still pointing at RdsSchemaLayer version 623:
Expected result
I expect that a new lambda version is created using RdsSchemaLayer version 624.
Additional environment details
sam --version: AWS SAM CLI 1.142.1 (deploying with Github runner https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md)