Lambda layers update the number version without code modifications.

[martinfernandezbon]

Description

I am using Serverless Framework to deploy my Lambda functions and Lambda Layers.

To create the Lambda Layers we create differents folders, each one for each layer where we can find in each folder the serverless.yaml file where we define the the lambda layer and the requirements.txt file where we define the python libraries dependencies. The requirements.txt file is used for the python requirements plugin (previously installed)

Folder structure:

├── layers
│   ├── <layer_name1>
│   │   ├── requirements.txt
│   │   └── serverless.yaml
│   ├── <layer_name2>
│   │   ├── requirements.txt
│   │   └── serverless.yaml
│   └── <layer_name3>
│       ├── requirements.txt
│       └── serverless.yaml
├── serverless.yaml
├── <app_folder>

We noticed that each time that we trigger the CI/CD pipeline for the application, the lambda layer version increase doesn't matter if the serverless.yaml and requirements.txt files have been updated or not. Each time that we run the pipeline, the "servererless deploy" command is being executed in a new container based in an ubuntu 22.04 docker image.

If we deploy from our local computer the lambda layer running serverless deploy it works as expected. I mean, If the code didn't change, no change request in the cloudFormation stack is created. But if we run exactly the same command into a new container, the first time it update the lambda layer version number, but the second time it works as expected, no change request is created.

If we stop the container and we create a new one, the same pattern occurs: The first time the lambda layer version increase (although we didn't have changes in the code) and next times it works as expected.

How to reproduce?

1. Run a new container from the base docker image ($docker run <image_name>)
2. Copy the repository content into the container ($docker cp <folder_name> <container_name>:<folder_path>)
3. Configure the AWS credentials in the docker container ($aws configure)
4. Install the python requirements in the root repository ( $cd <folder_path> && serverless plugin install -n serverless-python-requirements )
5. Go to layers/<layer_name> ($cd layers/<layer_name>)
6. Try to deploy a new lambda layer ($serverless deploy)

Result:

The Layer version increase (although the codes didn't change from the last deploy). If we execute again the point number 6, it recognize that not changes have been executed in the code, so doesn't update the version number.

Note: Each time that we execute the "How to reproduce?" process described above, a new folder .serverless is created.
In that folder we find pythonRequierements.zip and cloudformation-template-update-stack.json.

If we execute the process "How to reproduce?" again, the pythonRequierements.zip is different than before (the size is a bit bigger). But if we unzip both, they have the same content (same size and same number of files and folders).

If we analyze the cloudformation-template-update-stack.json we can see the following code snippet:

"PythonRequirementsLambdaLayerHash": {
  "Description": "Current Lambda layer hash",
  "Value": "**c4e6c87314753740433442c351cb57f503240bce**",
  "Export": {
    "Name": "sls-contributor-backend-layer-utils-dev-PythonRequirementsLambdaLayerHash"
  }
}

I could notice that the value for the PythonRequirementsLambdaLayerHash is different too.

Could be that the hash algorithm which is created for the current lambda layer depends of the OS where we are using the Serverless Framework?

Expected behavior:

The version number of the Lambda layer must be the same after run "serverless deploy" if the code for the lambda layer (serverless.yaml and requirements.txt files) didn't change.

I think that it should be a well known issue because it should happen each time that we integrate it in a pipeline. (And should be a common solution maybe ? )

Versions:

node version: v14.21.3
serverless framerwork version: 3.30.1