schema validations for environment variables fail

[dazza-codes]

For serverless 2.x, the schema validation fails for environment variables

With serverless.yaml that contains environment variables, e.g.

provider:
  environment:
    FLASK_ENV: development

functions:
  funcName:
    environment:
      ANY_ENV: avalue

The errors are like:

Serverless:   at 'functions.funcName.environment.ANY_ENV': unsupported configuration format
Serverless:   at 'provider.environment.FLASK_ENV': unsupported configuration format

serverless.yml

provider:
  environment:
    FLASK_ENV: development

functions:
  funcName:
    environment:
      ANY_ENV: avalue

sls package output

Serverless:   at 'functions.funcName.environment.ANY_ENV': unsupported configuration format
Serverless:   at 'provider.environment.FLASK_DEBUG': unsupported configuration format
Serverless:   at 'provider.environment.DATADOG_ENABLED': unsupported configuration format

Installed version

Framework Core: 2.2.0
Plugin: 4.0.4
SDK: 2.3.2
Components: 3.1.4

[medikoo]

@dazza-codes I'm not able to reproduce that error, also serverless.yml you've provided is incomplete (testing it out results with "service" property is missing in serverless.yml error).

Can you provide full content of serverless.yml (but minimal, without any plugins involved) ?

[sorenandersen]

Running serverless deploy on the following serverless.yml:

service: temp-aws-nodejs-hello

frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x
  environment:
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1

functions:
  hello:
    handler: handler.hello

will yield a warning like:

Configuration warning at 'provider.environment.AWS_NODEJS_CONNECTION_REUSE_ENABLED': unsupported configuration format

Installed version:

Framework Core: 2.3.0
Plugin: 4.0.4
SDK: 2.3.2
Components: 3.1.5

[janoist1]

I had the same issue after upgrading serverless from 1 to 2. What worked for me was to use a string value instead of integer. 1 👉 "1"

[thtliife]

I have the exact same problem.
And wrapping in quotes isn't always an option.

I use functions in my environment vars to grab things like a cloudfront distribution address, and reference that var in code for things like CORS responses.

Imagine the following:

service: temp-aws-nodejs-hello

frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x

functions:
  hello:
    handler: handler.hello
    environment:
      TEST_VAR:
        'Fn::Join':
          - ''
          - - 'foo'
            - 'bar'

do a serverless deploy with that serverless.yml and it will result in:

$ serverless deploy

  Serverless Error ---------------------------------------

  Configuration error at 'functions.hello.environment.TEST_VAR': unsupported configuration format

  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Issues:        forum.serverless.com

  Your Environment Information ---------------------------
     Operating System:          darwin
     Node Version:              14.12.0
     Framework Version:         2.3.0 (local)
     Plugin Version:            4.0.4
     SDK Version:               2.3.2
     Components Version:        3.2.0

This issue does not occur in v2.1.1 (The version my project was on previously)
It occurs for me from v2.2.0 onwards

[medikoo]

@sorenandersen in your case problem is that 1 translates to number 1, while supported notation is either string or some variants of intrinsic CF functions.

Simply write it as "1", and warning will be gone

[medikoo]

@thtliife Currently we do not support resolution of Fn::Join CF functions in env vars when processing local invocation of lambdas. It's the reason the validation reports given format as not supported.

Anyway we will happily accept a PR that brings that support (we already support resolution of Ref and Fn::Import), it's done here:

serverless/lib/plugins/aws/invokeLocal/index.js

Lines 188 to 192 in 7f47448

	if (value['Fn::ImportValue']) {
	resolver = resolveCfImportValue(this.provider, value['Fn::ImportValue']);
	} else if (value.Ref) {
	resolver = resolveCfRefValue(this.provider, value.Ref);
	} else {

[thtliife]

Thanks for the clarification @medikoo.
Join isn't all that important to me, it was just an example of failing a CF function.
The one i really need is GetAttr (Which i often use with join).
I will have a look in the next couple of days at adding support and creating a PR. :)

For now i will stick to version 2.1.1, as both those CF Functions work fine there.

[stevenj]

I am also getting this issue since upgrading:

custom:
  WSS_API_ENDPOINT:
    !Join [
      "",
      [
        "https://",
        !Ref WebsocketsApi,
        ".execute-api.",
        "${self:provider.region}",
        ".amazonaws.com/",
        "${self:provider.stage}/",
      ],
    ]
functions:
  WebsocketHandler:
    environment: 
      WSS_API_ENDPOINT: "${self:custom.WSS_API_ENDPOINT}"

This works totally fine, and i am not (and have no intention of) locally invoking the lambda. But i am still getting unsupported configuration format errors. But it is a supported and valid configuration format for non local invocations, so at the very least it should not be an error, but a warning that says something like "WARNING: format not supported for local invocation".

[medikoo]

For now i will stick to version 2.1.1, as both those CF Functions work fine there.

@thtliife Note, that in 2.3.0 all works same, the only difference is that config validation warning is issued

[medikoo]

@stevenj we're open to accept an option like enableDeploymentOnlyEnvVars: true, thorugh which config schema could be relaxed to accept all CF intrinsic functions in env vars. Having that if local invocation is issued with not supported env var format, meaningful exception could be thrown.

PR that introduces that is welcome

[medikoo]

@thtliife @stevenj handling of your case was just fixed with #8307 which was just published with v2.4.0 (after all I decided to not introduce any option, so it'll work out of a box).

[stevenj]

@medikoo Thankyou very much.

[tonivdv]

Hi @medikoo

@thtliife Currently we do not support resolution of Fn::Join CF functions in env vars when processing local invocation of lambdas. It's the reason the validation reports given format as not supported.

Anyway we will happily accept a PR that brings that support (we already support resolution of Ref and Fn::Import), it's done here:

https://github.com/serverless/serverless/blob/master/lib/plugins/aws/invokeLocal/index.js#L188-L192

I stumbled on this with a FN::Sub use case:

custom:
  someUrl: !Sub 'https://${self:custom.someDomain}'

Looking at the reference you gave and by debugging it, I noticed that the value of value['Fn::Sub'] was already computed. And thus in my case the fix would be as simple as:

          if (value['Fn::ImportValue']) {
            configuredEnvVars[name] = await resolveCfImportValue(
              this.provider,
              value['Fn::ImportValue']
            );
          } else if (value.Ref) {
            configuredEnvVars[name] = await resolveCfRefValue(this.provider, value.Ref);
          } else if (value['Fn::Sub']) {
            configuredEnvVars[name] = value['Fn::Sub'];
          } else {

Now, before pushing a new PR for this, I'm wondering if in the case of FN::Sub this will always be true? Or if others by experience can already tell me that I'm lucky here and other cases are more complex.

Thanks in advance

[medikoo]

@tonivdv this issue was actually addressed, I just forgot to close it (closing it now)

Now answering your question, why you're using Fn::Sub? In value you just use serverless variables, which are resolved independently. I believe your setup could be just:

custom:
  someUrl: https://${self:custom.someDomain}

[tonivdv]

Now answering your question, why you're using Fn::Sub?

That's a very good question. 🙈

Thanks