Amplify-cli: Manipulate environment variables for lambda functions

[eliecer2000]

Greetings, seeing that you do not modify an option in the CLI to be able to add the environment variables to each of my lambda functions, I saw the need to clone and modify the code, I already have the desired functionality in the option

amplify function update

? Please select the Lambda Function you would want to update functionName
? Do you want to modify the environment variables, given this Lambda function? Yes
? Please select the option you want to run Create a new variable
? Enter the variable name:  endpoint
? Enter the value of the variable:  http://dominian.com
? Do you want to change another one? Yes
? Please select the option you want to run List all variables
Variable List
endpoint  =  df654a6s5d4f6a5sd4f6as5d4f6a5sd4f6a5sd4f

? Do you want to change another one? Yes
? Please select the option you want to run Delete a variable
? Select the variable you want to delete  endpoint
? Are you sure you want to delete the variable?: endpoint? Yes
Variable deleted successfully
? Do you want to change another one? No

I have tried it and it works, it is possible that someone else needs this, my question is what is the procedure to request the RP to integrate it to the master branch.

Thank you

[edwardfoyle]

Hi @eliecer2000 this is something in our backlog that we want to support. If you would like to contribute a PR for it, you can read our PR guidelines here

[renebrandel]

hi @eliecer2000 - just providing a couple of comments here. I'm unsure if having this as a guided CLI flow is the fastest and most intuitive developer experience. My proposal for this:
in amplify add function at the end we provide a prompt saying

$ amplify add function
...
...
...
Place any environment variables into amplify/backend/function/<function-name>/amplify.env file

In addition when users want to mock the function locally, they can choose to override the env variables from amplify.env by providing this parameter:

amplify mock function --env-vars <path-to-env-file>

This way, the user can update the env variables on the fly faster without going through an entire guided flow using amplify update function and in addition, the user can have a "global" env variable file that they can pass into mock function through a param if they choose to.

[eliecer2000]

It is an excellent idea, but in that case the code that performs the push should be changed, since with the modifications that have been made the desired values ​​are placed in the file functionName-cloudformation-template.json that contains the data for the creation of the function.

[renebrandel]

Yeah - that's actually a good point.
My opinion if it's in amplify.env, we should take those vars and push it (as you suggest).
if it's passed in --env-vars then it remains local.

Thoughts?

[eliecer2000]

Hi @eliecer2000 this is something in our backlog that we want to support. If you would like to contribute a PR for it, you can read our PR guidelines here

excuse my ignorance on the subject, but I really do not have the knowledge of how the procedure is, I did a git clone, I do not know if I should have done a fork, anyway I would like someone to check it before doing a PR, you could Lean on that? Would you like to take a look?

thk

[edwardfoyle]

Hi @eliecer2000 no worries. You'll need to create a fork of the CLI repo in your GitHub account. Then pull that repo and make the changes. Once everything looks good and you have written tests for it (both unit tests and end-to-end tests which you can find information about here) you can publish a PR. If you want us to take a look at it before it's completely ready, you can publish a draft PR.

As far as implementation goes, here are a few things I think this feature should include (mostly taken from @brene's comment above with some modifications)

1. I would recommend storing the environment variables in the parameters.json file that is already created in the function folder under a new "environment" field in that json object.
2. These environment variables should be populated in the lambda cloudformation template on function update and push
3. These environment variables should be made available to functions when running amplify mock function
4. amplify mock function should take an additional --env-vars <filename> flag that will load additional environment variables (stored in json format) into the mock invocation. These variables should _only_ be used during mock (not pushed to the cloud)

Something else that would be nice to think about with this feature is multi-environment set-ups. For example you can imagine a scenario where a lambda calls an external API with an API key but you may want to use a different API key for your dev vs prod environment.

[sw-yx]

tagging a related Feature request issue for this feature - would be amazing to get this working! https://github.com/aws-amplify/amplify-cli/issues/2227

[cyrfer]

Please support Lambda runtime environment variables before worrying about user-provided variables.

I requested over here:
https://github.com/aws-amplify/amplify-cli/issues/4635

[TrungRueta]

@edwardfoyle
Having workaround for people who use Macos (or ubuntu).
create new file .env on root project.
install dotenv nodejs package.
add new script to packages.json : "mock": "node -r dotenv/config $(which amplify) mock"

this way we can implement all variables from .env file into session mocking. lambda functions will take env values without tounch on stack formation files.

[SwaySway]

Closing this issue in favor of #2227 for better visibility and tracking.