Lambda Code Hash changes after every git repository clone

❓ General Issue

The Question

I have an issue with our current CDK app.
Whenever a colleague clones the repo containing the CDK app and runs a cdk diff, all Lambda functions are rebuilt. Somehow, the hash which is calculated for every Lambda function in the CDK app changes.

This issue confuses our staff since they do not expect anything to change at all when they are not explicitly editing the Lambda functions.

Is it possible to make the hash computation more deterministic?
Actually, I do not know why the hash is changing for every full rebuild of the CDK app (i.e. removing all node_modules, cdk.out and bin directories).

However, I guess a solution would be to derive the Lambda’s code hash from the version attribute in each Lambda’s package.json file. Is this currently possible in the CDK?

Environment

• CDK CLI Version: 1.39.0 (build 5d727c1)
• Module Version: 1.39.0
• OS: Ubuntu
• Language: TypeScript

Other information

Example diff after the repository with the CDK app was checked out:

[~] AWS::Lambda::Function CoreBackend/CoreDeploymentHookConfirmationLambda CoreBackendCoreDeploymentHookConfirmationLambda46C41C7C 
 ├─ [~] Code
 │   ├─ [~] .S3Bucket:
 │   │   └─ [~] .Ref:
 │   │       ├─ [-] AssetParametersfa10a908065450dae7afcd3ef15c0cf60cb75272385a7fdcac361366cb354d56S3Bucket95C78B44
 │   │       └─ [+] AssetParameters700428d8041f177f9e37b4a632fde92deb0dd5d8315ccacd9b16905249cb515dS3Bucket872367FE
 │   └─ [~] .S3Key:
 │       └─ [~] .Fn::Join:
 │           └─ @@ -8,7 +8,7 @@
 │              [ ]   "Fn::Split": [
 │              [ ]     "||",
 │              [ ]     {
 │              [-]       "Ref": "AssetParametersfa10a908065450dae7afcd3ef15c0cf60cb75272385a7fdcac361366cb354d56S3VersionKeyC85B62DB"
 │              [+]       "Ref": "AssetParameters700428d8041f177f9e37b4a632fde92deb0dd5d8315ccacd9b16905249cb515dS3VersionKeyCDD40801"
 │              [ ]     }
 │              [ ]   ]
 │              [ ] }
 │              @@ -21,7 +21,7 @@
 │              [ ]   "Fn::Split": [
 │              [ ]     "||",
 │              [ ]     {
 │              [-]       "Ref": "AssetParametersfa10a908065450dae7afcd3ef15c0cf60cb75272385a7fdcac361366cb354d56S3VersionKeyC85B62DB"
 │              [+]       "Ref": "AssetParameters700428d8041f177f9e37b4a632fde92deb0dd5d8315ccacd9b16905249cb515dS3VersionKeyCDD40801"
 │              [ ]     }
 │              [ ]   ]
 │              [ ] }
 └─ [~] Metadata
     └─ [~] .aws:asset:path:
         ├─ [-] asset.fa10a908065450dae7afcd3ef15c0cf60cb75272385a7fdcac361366cb354d56
         └─ [+] asset.700428d8041f177f9e37b4a632fde92deb0dd5d8315ccacd9b16905249cb515d

[joraycorn]

A simple repro : https://github.com/joraycorn/cdk-lambda-absolutepath

1. Clone & build/diff & deploy
2. Move the whole cloned folder somewhere else
3. Diff again without changing anything.

I would like to know if theres any work around for that case. A more real world case would be having 2 dev working on the same environment. At the moment, it take ~10 min to deploy our stack changes even though we haven’t modified any files in them. Same goes for layers.

Thanks !

[MartinLoeper]

Yes @nija-at you are correct that this would be expected behaviour of the cdk in the first place.

However, people who are responsible for building functional repositories must somehow find a solution to handle this case.

The issue is the following: If you have a cdk app with a lot of TypeScript lambda functions and another person checks it out and deploys it, a lot of assets are uploaded. This leads to the following two inconveniences:

a) The deployment is slowed down. b) People that request a diff via “cdk diff” often come to me and are confused that there are more changes which the cdk wants to roll out than they have intentionally caused.

Solution: Shouldn’t it be possible to create an attribute for the NodejsFunction construct [1] which instructs the asset’s hash being computed based on the underlying sources only? This attribute could be totally optional and defaulted to false. What do you think? Does it make sense?

Let me put it another way: Does it make sense not to care about the generated lambda handler, but to specify a list of files which are used instead for change detection (e.g. package.json and the dist/ folder)?

[1] https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-nodejs-readme.html