When creating lambda functions through amplify function add amplify creates CloudFormation template. This template is meant to be stored in the git repository (because it describes lambda and can have manual changes). The problem is that on each amplify push this file is modified with the following lines:
"Code": {
"S3Bucket": "<bucket-name>",
"S3Key": "<build-zip-file-name>"
}
Later you need to either manually rollback files in git or resolve merge conflicts for those lines which makes no sense.
I propose to not update those files and perform all generation in the temp files
@artyom-melnikov The S3Key and Bucket needs to change whenever there is an update in your src/ code. This needs to change to trigger a build in Cloudformation (For Cloudformation to detect a change) and re-deploy your lambda with a changed source code. Do you see this behavior even when there are no changes to your source code?
No i don't see this behavior when code is not changed. I see this when i'm initing new env. My team use amplify end each team member has own dev environment. Therefore each one of us has different S3Key and S3Bucket params and we have issues storing this templates in git because of that
@artyom-melnikov Yes, we're aware of this. This wouldn't cause any issues deploying since the keys are generated dynamically on each push. We are looking at a solution where we build the S3Key based on the hash code of the src code - that way the key is consistent across multiple environments and sandboxes.
Any progress? This problem is really annoying!
Is there an RFC that would provide guidance to the community if the core dev team is not prioritizing this?
@kaustavghosh06
A cdk provider for amplify, where the amplify implementation used the fromAsset method of the cdk lambda module would also address this...
@renebrandel this needs attention. How about building a docker image of the lambda artifact to know if any change occurred rather than always bundling the lambda for each deploy. Also, the artifact path should be passed to the stack as a parameter, not by modifying the template.
Most helpful comment
Is there an RFC that would provide guidance to the community if the core dev team is not prioritizing this?
@kaustavghosh06