Allow boolean environment variables

[danilofuchs]

Use case description

Currently, Serverless only allows string values as environment variables. This is completely acceptable, as envs can only be strings.

My use case is the following:

provider:
  name: aws
  runtime: nodejs12.x
  tracing:
    # Turn this on when needing to debug timing
    lambda: true
  environment:
    XRAY_ENABLED: "${self:provider.tracing.lambda}"

true is boolean, so when validating, serverless will raise the warning:

Serverless: Configuration warning:
Serverless:   at 'provider.environment.XRAY_ENABLED': unsupported configuration format

But, during runtime, XRAY_ENABLED will be "true" (string).

I cannot use lambda: "true" as the field expects a boolean.

Proposed solution

Serverless should allow usage of boolean values on environment variables with no warnings about unsupported configuration, as it is clearly supported (it converted to string after all)

I understand I could look into some weird workarounds using the custom field, but I feel it would be hard to understand in the future.

[medikoo]

@danilofuchs Thanks for report.

We have ${strToBool(...), and I believe we can also have ${boolToStr()}.

PR that provides that is welcome!

[oviecodes]

How do I get started with this? @medikoo

[danilofuchs]

Perhaps a more general $toString() function could be added?

Maybe limit it to booleans and numbers at first

[oviecodes]

Please point me to the file that should be worked on

[liberalterian]

Hey guys, can we simply add an expected type to the lambda variable in awsProvider.js?

tracing: { type: 'object', properties: { apiGateway: { type: 'boolean' }, lambda: { type: 'boolean', $ref: '#/definitions/awsLambdaTracing' }, }, additionalProperties: false,

I will submit a pull request with the above changes if you think this solves the problem. I apologize if this was a naive solution, this is my first contribution.

[medikoo]

@oviecodes @danilofuchs after giving this a bit more thought I decided that it'll probably be good to simply coerce given values where possible. AJV schema validation engine which we use to validate input configuration, has such functionality built in. I've proposed a PR that enables that: #8319

As a side comment, in my experience, best way to propagate boolean values in env vars is simply via existence check (if XRAY_ENABLED is set, it means it's enabled, otherwise it's not enabled), as coercing strings to booleans is quirky and prone to errors.

To adapt in your case to that, you may probably define XRAY_ENABLED as ${self:provider.tracing.lambda, null}, and not set tracing.lambda at all, if XRAY is not intended.

[maghirardelli]

@danilofuchs Thanks for report.

We have ${strToBool(...), and I believe we can also have ${boolToStr()}.

PR that provides that is welcome!

I ran into this issue and made a simple bool-to-str.js file that read in the environment setting that was a boolean from serverless.yml. Then, serverless.yml used the output from bool-to-str.js (which was a string) in its evaluation of a condition instead. Inspiration from this Stack Overflow thread. See my full PR here, but really only the bool-to-str.js and serverless.yml files are relevant to this issue: awslabs/service-workbench-on-aws#715

Edit: reading from serverless.yml doesn't work exactly how I thought as the variables in serverless.yml are not evaluated until runtime. Instead, I retrieved the value from another location in the code base and still was able to convert it properly to a string to be used in the serverless.yml file. Fix PR here: awslabs/service-workbench-on-aws#730.