Make params load only for relevant stages

[sheen4n]

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Use case description

Example serverless.yaml snippet

params:
  default:
    FOO: 'BAR'
  prod:
    FOO: ${ssm:/aws/reference/secretsmanager/FOO}

There is no secrets called FOO in all stages except for stage prod environment.

When I perform serverless print --stage dev with the stage dev awscli permissions, there is an error:

Error: Cannot resolve serverless.yml: Variables resolution errored with:

• Cannot resolve variable at "params.prod.FOO": Value not found at "ssm" source

Likewise, if I use this yaml:

params:
  default:
    FOO: 'BAR'
  dev:
    FOO: 'BAR'
  prod:
    FOO: ${ssm:/aws/reference/secretsmanager/FOO}

When I perform serverless print --stage dev with the stage dev awscli permissions, there is the same error as above. (only prod is the secret available, the rest of environment, I want the value to be hardcoded)

---

Summary of Feature/ Issue:

params should only load for the stage that is relevant, for example, in this case, I am only interested in dev stage, why should it resolve a secrets from another stage?

Thank you :)

Proposed solution (optional)

I propose to make the params only load for relevant stages based on stage input.

Example if --stage dev is passed into sls arguments,

It will not try to load ssm variables that is not relevant.

if params.dev.FOO is available, load that only.

else if params.default.FOO is available, load that

else FOO is null or blank for stage dev, but it will never try to load secrets or ssm for another stage.

[doulighan]

+1, I feel this is genuinely harmful on production, for two reasons:

1. Production really shouldn't be leaking variables to other stages

2. Using ${value, null} in order to satisfy this requirement completely kills the usefulness of having SLS throw errors when env variables are missing. I want SLS to fail during deploy if a stage variable is missing, but that is impossible with this setup.

I understand this isn't how yaml works, but it seems like an important blind spot to consider

[austencollins]

This isn't good. Writing a fix now and including it in v4.