Amplify-cli: Multi environment lambda layer hard codes environment

[davekiss]

Describe the bug
I have two environments and have created a new lambda layer. When I add the lambda layer to a function in the first environment, the CFN template for that function injects the current environment's layer value as a hard coded value from the env it was created in, rather than the environment that the build is/will be occurring in

https://github.com/aws-amplify/amplify-cli/blob/bffaded7351e3bfbcb67fede139b3dab7770eda4/packages/amplify-category-function/src/provider-utils/awscloudformation/utils/lambda-layer-cloudformation-template.ts#L154-L158

Amplify CLI Version
4.29.4

To Reproduce

1. Create two environments
2. Add a single lambda layer to both
3. Add the lambda layer to a function in environment A
4. Check the output of Layers in function-cloudformation-template.json – the value contains a hard-coded env

Expected behavior
The string value should contain a reference to Ref:env to pull the environment value from the current build environment rather than the environment where the layer was added to the function

Desktop (please complete the following information):

• OS: Mac
• Node Version. 10.15.3

Additional context

https://github.com/aws-amplify/amplify-cli/blob/bffaded7351e3bfbcb67fede139b3dab7770eda4/packages/amplify-category-function/src/provider-utils/awscloudformation/utils/lambda-layer-cloudformation-template.ts#L154-L158

[jhockett]

Hi @davekiss, thanks for pointing this out. I'm marking this as an enhancement.

[kenbankspeng]

Not sure if this is the same issue or not, but I have a multi env, and a lambda layer was created in env A. When I merged this into env B, although amplify push created a new lambda layer in env B, it linked the lambdas of env B to the layer of env A.

So, just my opinion, but I am struggling with the enhancement tag. To me, this means that amplify cli doesn't yet support layers in a multi env. If env B is production and env A is dev, sorry, but I can't have production code dependent on a piece of dev code.

[davekiss]

@kenbankspeng @jhockett totally agree, it'd be one thing if the amplify push did replace the env value but that is not the case, env is only replaced when adding the layer to the lambda. This is a bug, not an enhancement.

[kenbankspeng]

I just performed a little test. I enhanced the lambda layer code in env B, did a push and as expected got a new version of the layer in env B, but was my jaw dropped after observing that the lambdas in env B still link to the now out-of-date code in layer A. Sorry, but a configuration management nightmare and not a feature that can be used for production.

I do really appreciate the value that a lambda layer can add. I do hope this can be resolved quickly. Thank you.

[waynebrantley]

@davekiss Agree with you - this is a bug. @jhockett - the env name is not replaced with the current environment when you execute amplify push

[jhockett]

Apologies, I misunderstood the issue and my previous comment didn't make sense (now edited to avoid confusion).

The reason I marked this as an enhancement, is because the layer referenced in the function can be updated with amplify update function to reference the new environment and correct version. This solution is tedious and we can definitely improve the developer experience here.

I think it's fair to expect the update to be automatic when performing amplify env checkout, so I'll change the label to a bug. Thanks for all the feedback!

[waynebrantley]

One thought would be:

• environment - have the ${env} in the name of the layer as suggested above. This would mean the checkout code would not have to do anything when checking out different environments (as well as create environment not having to change).
• version - have a variable ${latestVersion} that always points to the latest version of the lambda for the given environment. This would mean when checking out a new environment as long as the 'latest version' in that environment was set when creating/checking out. If for some reason the 'layer' needed to be pinned - this would be a manual step - much like it is now.

Given these two ideas, seems like it would not be too bad of a fix?

[waynebrantley]

@jhockett Any update on this?

[aaronbrighton]

I've also ran into this issue attempting to use Lambda layers in a multi-environment team, would like to avoid having to run amplify update function each time someone pulls in code from others.

Any update?

[jhockett]

Hi all, we are actively looking into reworking how layer versions work in the CLI, so fixing this issue will likely either coincide or follow that update.

[gakinson]

Hey I noticed there was a fairly large amount of changes released in the latest version of Amplify. I was wondering if this was covered, it was not super clear if it was based on the changelog.

[jhockett]

Hey I noticed there was a fairly large amount of changes released in the latest version of Amplify. I was wondering if this was covered, it was not super clear if it was based on the changelog.

Sorry for the confusion @gakinson, but the layer versioning hasn't changed yet. I will update this issue as soon as there is more to share.

[akash87]

I was able to resolve it by replacing it with lambda layer arn in the cloudformation file. Layer ARN is available as an environment variable.

[waynebrantley]

@akash87 That is a fantastic solution!
@jhockett The layer thing needs some attention in a big way.
In fact, a great solution would be to let lambda's in an amplify project reference javascript files outside of their folder. This is probably the 80% use case anyway - just some shared code among a few lambdas. Don't necessarily need the whole shared layer concept. https://github.com/aws-amplify/amplify-cli/issues/2295 https://github.com/aws-amplify/amplify-cli/issues/1696

In the meantime a change to the above would help anyone using lambda. For now, a few manual edits and this is much better.