2

I am trying to set the serverless service name from the env file. Before deploying serverless, I have set the value of ECR_NAME as

export ECR_NAME=$(echo $CI_ENVIRONMENT_SLUG | awk -v srch="-" -v repl="" '{ gsub(srch,repl,$0); print $0 }')

Then I have written it as below in the serverless.yml.

service: ${env:CI_PROJECT_NAME}-${env:ECR_NAME}

useDotenv: true
configValidationMode: error
variablesResolutionMode: 20210326

Getting the below error:

Error:
Cannot resolve serverless.yml: "service" property is not accessible (configured behind variables which cannot be resolved at this stage)

Installed version

Framework Core: 3.14.0
Plugin: 6.2.1
SDK: 4.3.2
paulsm4
  • 114,292
  • 17
  • 138
  • 190
Nowshad Ibne Amin
  • 31
  • 1
  • 4
  • Q: Exactly what kind of "serverless framwork" are you using??? Please specify vendor and product!!! (I'm guessing AWS Docker/AWS ECR?) – paulsm4 Apr 18 '22 at 23:44
  • We are deploying to AWS Lambda and using container image. Serverless Framework version: 2.32.0 We could set the service name dynamically from env variables before version upgrade. Since version 2.32.0, when attempting this, the commands fail with the following error: Cannot resolve serverless.yml: "service" property is not accessible (configured behind variables which cannot be resolved at this stage). – Nowshad Ibne Amin Apr 19 '22 at 16:17
  • please update your current status – paulsm4 Apr 22 '22 at 16:54

1 Answers1

2

See Issue #9313 on GitHub:

https://github.com/serverless/serverless/issues/9813

Problem:

The latest version of the serverless framework is no longer working for AWS Lambda deployments and is throwing the following error:

Cannot resolve serverless.yml: “provider.stage” property is not accessible (configured behind variables which cannot be resolved at this stage)

Discussion:

with the new resolver, such definition is not supported. In general, it is discouraged to configure stage behind env variables for example, as at the point where stage is going to be resolved, not whole env might be available (e.g. loading env vars from .env.{stage} needs to resolve stage first in order to properly load variables from file), which might introduce bugs that are hard to debug. Also, the provider.stage serves more as a "default" stage and --stage flag via CLI is the preferred way of setting it.

...

In your configuration file you explicitly opt-in to use new resolver via variablesResolutionMode: 20210326 variable.

We are not discouraging the use of env variables - quite the contrary, we've been promoting them as a replacement for custom CLI options for example and it is generally a great practice to use them. As for env source for stage specifically, this has been introduced as a fix, as stage should be already resolved before we attempt env variables resolution, as loading .env files can depend on stage property. @medikoo I know we've talked about it today, do you think it could be safe to resolve stage from env source in specific circumstances (e.g. when dotenv is not used)?

See also:

paulsm4
  • 114,292
  • 17
  • 138
  • 190