Amplify-cli: Stop storing S3 bucket Lambda deployment information under Git

[xavierraffin]

Is your feature request related to a problem? Please describe.

When you work in a team on a project with multiple Amplify envs, you merge code from multiple developers in a main branch (at some point).
The problem is that the Git history and the code reviews are polluted by changes done when switching environment instead of real code changes.
To be more specific, all the CloudFormation scripts under amplify/backend/functions/XXX contains section like this:

"Code": {   
    "S3Bucket": "blabla-env-123456-deployment",
    "S3Key": "amplify-builds/blabla-1234567890123456-build.zip" 
},

Because the S3Key and S3Bucket is different for all env (and the S3Key even change between push) these value change all the time creating a lot of fuzz in the Git commits.

Describe the solution you'd like

I like to have the Amplify CLI dynamically injecting that information when pushing and removing the hardcoded values from the CloudFormation files.
Like having:

"Code": {   
    "S3Bucket": "DO-NOT-CHANGE-UPDATED-BY-AMPLIFY-CLI",
    "S3Key": "DO-NOT-CHANGE-UPDATED-BY-AMPLIFY-CLI" 
},

And if the Amplify CLI needs to store the information about those URLs please use team-provider-info.json for information that remains and a file that is under .gitignore for the information that changes at every push.

[ammarkarachi]

@xavierraffin Thanks for feature request this looks like there is some room for improvement I will mark this as an enhancement.

[ahtokca]

@xavierraffin was going to create exactly the same feature request! Thanks

[aaronbrighton]

Also, interested in this enhancement or bug fix.

SAM CLI (sam package command) appears to handle this differently than Amplify - by replacing the local artifacts with the Amazon S3 location in a newly generated template file used for deployment (sam deploy), instead of updating the source template file.

Seems like similar environment specific pollution exists in the CF templates with Lambda layers (#5479) and in S3AndCloudFront parameters.json (#711).

[r0zar]

I agree this is an enhancement.

@ammarkarachi do you know who's working this at the moment? I wouldn't mind picking it up if it's looking for an owner.

I'd also be interested to chat on the ideal solution. Resolving the S3Bucket seems straightforward considering it already present in team-provider-info.json. The S3Key leaves a little to be improved on, considering it would be nice to generate only 1 hash for the entire build, and use that for all lambdas. Interested in your thoughts on this one. Thanks!