Amplify-cli: Lambda cloudformation json changes between env pushes

[hisham]

Describe the bug
Everytime I switch envs and do a push the *-cloudformation-template.json of my lambdas (in amplify/backend/function) changes. These files are not in .gitignore (and I believe shouldn't).

Screenshot of the diff with change highlighted:

To Reproduce
Steps to reproduce the behavior:

1. Create function in one env
2. Checkout another env and push
3. See what files changed

Expected behavior
Random changes like this should be in .gitignore files.

Desktop (please complete the following information):

• OSX

Additional context
Running amplify cli v1.4

[kaustavghosh06]

@hisham Each time there is a change to the Lambda function source code, for Cloudformation(CFN) to re-deploy the lambda function, the S3 bucket key needs to change otherwise Cloudformation wouldn't know that there is a change to the Lambda function and won't re-deploy your functions and that's why you see the diffs in the CFN files. Do you have any specific suggestions as to how we can get around this?

[hisham]

I'm no cloudformation expert, but maybe there's a way to extract the s3 bucket info into a parameters file or nested stack of some sort that can be added to .gitignore. It seems you do something similar in the graphql nested stacks stuff where the s3 bucket info is just a variable:

        "RequestMappingTemplateS3Location": {
          "Fn::Sub": [
            "s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers...

[hisham]

The other annoying thing here is when I switch back to the first env and do amplify status, it shows that my functions need updating, which is quite annoying, because they don't really need updating and it sort of freaks me out at first glance because I'm wondering what changed that requires it to update.

[thde]

We're also having trouble with this. Because we use the CLI in CI, the init function seems to fail because of this. To pass it as a parameter would make more sense to me aswell.

[OtterFlip]

@kaustavghosh06 We are also experiencing this same issue. It's messing up our multi-env deployment and it's pretty aggravating. I agree with @hisham that this should be parameterized so that the template itself is unaltered when you switch between backend environments using "amplify env checkout " We also noticed, as @hisham mentioned, that a parameterized technique is used for the graphql stack (see his comment above).

When no lambda code has changed, and no resources have been altered, just switching environments with "amplify env checkout" should not cause both git and amplify status to report changes. When the only thing that has been done is to switch backend environments, git should report not changes and amplify status should report no changes (other than that you are now checked out on a different backend environment).

When no changes have been made to your function, simply switching environments with "amplify env checkout" causes "amplify status" to report that your function is altered. Git also reports changes to your function's cloud formation template. Also, and worse, it's possible to get into a bad state where the S3 bucket and key are pointing to the wrong backend environment than the one that is currently checked out with "amplify env checkout". We have a highly-customized multi-env deployment and everything is working now with Amplify CLI except for this one issue. Ug.

EDIT: We are experiencing the above issues with amplify cli version 1.6.10

[fiveanddone]

I wanted to add, we run into this today. I'd like to know how everyone is getting around this other than handling git conflicts?

I also wanted to add, that it's not possible to just put the files in .gitignore if you're using amplify console for continuous deployment because it fails in the build process.

This thread seems to be the same issue and suggests it's safe to remove so it's confusing: https://github.com/aws-amplify/amplify-cli/issues/968

[houmark]

Also affect my project, hitting git merge conflicts and just some confusion.

Any update on if the CLI team is working on improving this?

[kaustavghosh06]

@houmark Are you using the latest version of the CLI? With the latest version of CLI, which was merged as a part of this PR - #1668 we now use the hash of your lambda function source-code and the package-lock to determine the S3 keys, so that they don't change on every deployment (which was previously using deployment timestamps causing merge conflicts). Please feel free to re-open or comment on this thread if you're still facing this issue.

[houmark]

I am using the latest CLI 1.7.8.

Not sure what's going on exactly, but it may be related to also using Amplify Console to deploy which seems to create even more issues in the CLI because it thinks there are updates to do, when there are not. I am about to submit a question here to clarify how best usage is of both tools.

[slaat]

@kaustavghosh06 are you sure? I am using amplify 1.7.8
The S3Key on a lambda function changed after doing amplify push. I tried it on a project that existed with the "old" aws-amplify cli, maybe that is the issue?

[kaustavghosh06]

Yes, if you see this behavior with a consequent push with the new CLI, without making any change to your Lambda code, let me know.

[slaat]

Ohhh I get it. Yeah I will let you know if I see any issues. If this works out it would be super helpful. Thank you!

[hisham]

@kaustavghosh06 for people using yarn it seems like this issue still exists because you're using package-lock which is npm specific...

[houmark]

I'm using npm and I have not had issues with merging develop into master since my last comment.

[dyangelo-grullon]

I'm experiencing this issue on 4.9.0 as well. Every time I push to a different environment, the following gets set on all of my functions

                "Code": {
                    "S3Bucket": "******-{someEnv}-****-deployment",
                    "S3Key": "amplify-builds/****.zip"
                }

The s3 bucket and s3 key are environment specific.
This is infuriating. It's one bug after the other.

[kaustavghosh06]

@kekkler The S3Key needs to change per env and it gets generated at runtime for every push, so that Cloudformation is aware of the change in your source code and re-deploys your Lambda function. Did you see any discrepancies in the deployed Lambda or did the push fail?

[dyangelo-grullon]

amplify/backend/function/**AuthPostConfirmation/**AuthPostConfirmation-cloudformation-template.json

is where these s3 keys are set. Under the resource:

"Resources": {
        "LambdaFunction": {
            "Type": "AWS::Lambda::Function",
            "Metadata": {
                "aws:asset:path": "./src",
                "aws:asset:property": "Code"
            },

[dyangelo-grullon]

This should be passed into the template as a parameter, so that the template remains agnostic to the environment.

[willrust]

Right off the bat with a new project using 4.12.0 and merging changes from dev env to master env starts a cycle of conflicts for function S3 bucket names were the env suffix is the dif. Why?

[dyangelo-grullon]

This ticket needs to re-opened

[alexkates]

How is this usable? Is anyone actually deploying more than 1 environment with lambda functions? How are you managing the s3 keys when using more than one branch?

[BennettSmith]

This issue is closed, but seems to remain for many of us. I am running the Amplify CLI version 4.18.0 and run into this issue on each and every switch between environments.

@dabit3, I'm wondering if you could offer any suggestions for how we can get multi-environment deployments to work reliably without continually risking messing up these cloudformation templates.

[hisham]

Yes I agree. Still seeing this issue. Git changes whenever I deploy to different env is annoying.

[evanlarkin10]

I am also having this error still, any fix or workaround?

[grigull]

Running 4.19 CLI and this is still an issue.

[paulnolan7]

We are using amplify CLI version 4.21.1 and also have this issue.
But it's not the key that is changing it is the s3Bucket parameter since it has the environment name in the bucket name.

[dubchoi]

Can we re-open this? Still seeing it in 4.21.3

[paulnolan7]

Hi @kaustavghosh06 can we re-open this? It is the s3Bucket parameter that is changing when the env changes. Or is there another open issue that address this.

[kylekirkby]

@attilah @UnleashedMind any ideas how we can solve this?

[hyungjunk]

still experiencing 4.28.0

[patrykkrz]

4.29.4 - the same problem