Lambda environment variables#2748
Conversation
| newFunction.Properties.Description = functionObject.description; | ||
| } | ||
|
|
||
| if (functionObject.environment) { |
There was a problem hiding this comment.
This entire if block can be represented as:
newFunction.Properties.Environment.Variables = Object.assign({}, this.serverless.service.provider.environment, functionObject.environment)
- assign can take multiple arguments
- assign will ignore undefined things
(also this would allow specifying env in the service that applies to all functions; as it stands this code would only assign service-level environment variables if the function also defines them)(
|
Might be worth validating keys of |
|
@braahyan Damn! That is so awesome! 👍 👏 🎉 Thank you very much for this! We'll review and test it thoroughly ASAP. |
|
This PR also gives plugins the ability to inject environment variables: 'use strict';
const BbPromise = require('bluebird');
class EnvironmentVariableInjector {
constructor(serverless, options) {
this.serverless = serverless;
this.hooks = {
'before:deploy:compileFunctions': () => BbPromise.bind(this)
.then(this.beforeDeployResources)
};
}
beforeDeployResources() {
if(!this.serverless.service.provider.environment){
this.serverless.service.provider.environment = {}
}
this.serverless.service.provider.environment["INJECTED_FROM_PLUGIN"] = "asdfdasdfasdfdf"
}
}
module.exports = EnvironmentVariableInjector; |
|
Great @braahyan you've done an awesome job here! 👍 🎉 |
|
I think an obvious enhancement would be to drop the Ref attributes from cloud watch into the environment a la https://github.com/rurri/serverless-resources-env |
There was a problem hiding this comment.
Thank you very much for this PR! I really love the simplicity! Great job @braahyan 💯 🎉
I just added a comment that we might want to check if the environment property is given and then create the corresponding CloudFormation parts.
This will reduce the template size a little bit and removes the need to update all the function related template tests (as we need to add an empty property for the environment variables so that the tests succeed).
| newFunction.Properties.Description = functionObject.description; | ||
| } | ||
|
|
||
| newFunction.Properties.Environment.Variables = Object.assign( |
There was a problem hiding this comment.
Is there a way to create this only if an environment property is given on the function or provider level?
This way we won't have to add the empty property to every test (and reduce the template size a little bit).
|
|
||
| Object.keys(newFunction.Properties.Environment.Variables).forEach((key) => { | ||
| // I pulled this from the bash man pages | ||
| if (!key.match(/^[A-Za-z_][a-zA-Z0-9_]*$/)) { |
There was a problem hiding this comment.
Does this apply for the Lambda environment variables as well?
|
@braahyan just a quick update. |
| ``` | ||
|
|
||
| You can use [python-dotenv](https://github.com/theskumar/python-dotenv) to load files with environment variables. Those variables can be set during your CI process or locally and then packaged and deployed together with your function code. | ||
| Or if you want to apply Environment Variable configuration to all functions in your service, you can add the configuration to the higher level `provider` object, and overwrite these service level config at the function level. For example: |
There was a problem hiding this comment.
I find the last part a bit confusing. It looks liked overwrite these service level config at the function level is part of the goal, but sometimes I want to have an environment variable available to all of my Lambdas
|
Just pushed the minor updates and tested it again. Works fine! GTM from my side! |
|
Looks good to me 👍 |
|
Is it too early for 🍻 ? |
|
@nicka don't think so, cheers dude |
|
LOL |
|
Exciting! |
|
We should probably update the sample config that gets created with sls create! |
|
@braahyan Ah you mean the That's a good idea! |
|
@braahyan We'll add it to the templates in the next hrs. Thanks for the suggestion! 👍 |
|
First of all, I appreciate serverless and all the contributors immensely and I don't want to minimize that. But was there a place where discussion happened on this feature? This closes proposal #2673 (which had no substantive public discussion). I still don't even fully understand what's been implemented (still reading the commit). From the outside, it looks like there's a lot of time pressure to implement features as quickly as possible without taking the time to plan and discuss. What I'm saying is, I'd like to participate in public design discussions or at least observe those discussions (even after the fact), but I'm not sure where/when that's happening. Is it happening? |
|
Hey @stevecrozz We've added more This PR is just a starting point for environment variable support. We'd like to add enhancements soon so that it get's even more valuable. This means that we love to hear feedback and design proposal for future features / enhancements. We've opened up a separate issue with the pending proposals so that we can continue the discussion there (#2764). Thanks for bringing this up @stevecrozz 👍 . Feedback is one of the most important resources for us. |
|
@stevecrozz I went through the whole thread and I also read your comment. We discussed the implementation. We also took into account your comment. I will share an example on how to implement the approach you mentioned here. We believe the current implementation a very generic one we found to be applicable for various real-world use-cases. There are many how we can improve it. So for once we would love to have your input there, but I'm also curious how you would like to see us dealing with new feature requests. How can we do better? |
|
If this gets released as part of v1.2, aren't we committed to maintaining support for it in its released form (backwards compatibility) for the long haul? If so, we're jumping into that commitment rather quickly. This team is highly impressive in terms of how quickly these features can be implemented. But personally, I'd prefer to put more focus on stability of the framework and less on time-to-market. Where's the fire? Sure lots of users want environment variable support (I'm one of them), but would I want it one way in 1.2 and then a different backwards incompatible way in 1.3? Not at all. But maybe this is where I'm out of step with the rest of the community. One last thought. This is maybe not the most appropriate place for me to have started a meta-discussion on process and project philosophy. Where can we have these discussions? I don't see a public mailing list and I've had these larger questions with no place to ask them. If there's nothing like this, I'd suggest setting something up. |
|
Stability is definitely our highest priority. We follow semver so until a 2.0 is released nothing is going to go away only added or fixed. So yes, whatever we have now will be reported for quite some time as we don't plan 2.0 anytime soon. I'm not sure if we move to fast or too slow. Some people wanted to have the feature asap, some want to discuss for a while. It's a trade-off we needed to make … The whole team is hanging out in the #serverless_framework channel here: https://wt-serverless-seattle.run.webtask.io/serverless-forum-signup |



What did you implement:
Lambda environment variable support.
Closes #2673
How did you implement it:
Added a new property to the function template object and then used Object.assign to merge the dictionaries from the provider object and the function object.
How can we verify it:
serverless.ymlhandler.jsTodos:
Is this ready for review?: YES