sls print is including deprecation text

[thetumper]

Yes, version 2.16.0

I'm using "sls print" within a bash script to resolve variables. This is read from YAML format, and piped to a an output file which is also expected to contain YAML. The deprecation text is also written out, which renders it invalid YAML when trying to parse/query with yq library.

Apologies, I cannot include the full configuration. Regardless - there is nothing special to this issue; it simply requires a version of serverless for which "sls print" includes the deprecation text as output, and a script using yq to read any arbitrary property from it.

sls print \ --stage ${SLS_STAGE} \ --region ${AWS_REGION} \

/tmp/serverless.yml

⚠️⚠️ REPLACE WITH FULL COMMAND OUTPUT

myservice-api | Y A M L Exception -------------------------------------- myservice-api |
myservice-api | incomplete explicit mapping pair; a key node is missed; or followed by a non-tabulated empty line in "/var/task/serverless.yml" at line 1, column 32: myservice-api | Serverless: Deprecation warning: Starting with next major versi ... myservice-api | ^ myservice-api |
myservice-api | Get Support -------------------------------------------- myservice-api | Docs: docs.serverless.com myservice-api | Bugs: github.com/serverless/serverless/issues myservice-api | Issues: forum.serverless.com myservice-api |
myservice-api | Your Environment Information --------------------------- myservice-api | Operating System: linux myservice-api | Node Version: 10.18.0 myservice-api | Framework Version: 2.16.0 myservice-api | Plugin Version: 4.3.0 myservice-api | SDK Version: 2.3.2 myservice-api | Components Version: 3.4.3

⚠️⚠️ REPLACE WITH `serverless --version` OUTPUT

[pgrzesik]

Hello @thetumper, thanks for reporting that.

In fact, we have an option to set environment variable SLS_DEPRECATION_DISABLE to a comma-separated list of deprecation codes that you'd like to ignore, however, that option is not documented. I believe it would be great to improve our docs in that regard and we'd be happy to accept a PR with that.

Please let me know if that option works for you and if that's the case, would you be okay with me editing the issue a bit, so it's about improving documentation instead?

[thetumper]

Hi @pgrzesik , I will try the env variable, to see if it will provide a workaround. What is the full list of deprecation codes?

It does seem like a bug, though. The CLI docs for sls print give the information that the output should be the configuration with resolved variables, in either JSON, YAML or text format, with YAML being the default. With the insertion of the deprecation messages, it is not valid YAML.

So - I think the env variable may provide a workaround. But the correct fix is to not output such messages from sls print at all.

[thetumper]

The env variable worked. Thank you for that! Specifically, I used in my bash startup script:

export SLS_DEPRECATION_DISABLE=*

[thetumper]

Unfortunately, I cannot add the env variable in our server environment. The export will only work in my local. Really leaning on the correct solution to be implemented -- the warnings should not be part of "sls print" output. The Serverless CLI docs say that the command will:

"Print your serverless.yml config file with all variables resolved."

The format option is specified:

format Print configuration in given format ("yaml", "json", "text"). Default: yaml

Thus, it is expected that the output should be valid YAML by default. It is not.

[pgrzesik]

Hello @thetumper, thanks for reporting back. As for using the variable, I believe you should still be able to prepend your command with SLS_DEPRECATION_DISABLE, e.g. SLS_DEPRECATION_DISABLE='*' sls print.

What is the full list of deprecation codes?

Unfortunately, we don't have the codes listed anywhere in the documentation, but I've just opened an issue that aims to improve existing deprecation documentation: https://github.com/serverless/serverless/issues/8665

As for not including warnings in print command, we have a plan for a bigger refactoring/improvement of our logging mechanisms: https://github.com/serverless/serverless/issues/1720 which we will be prioritizing in the near future. That should resolve issue with print as well.