Normal messages are sent to stderr from serverless

Serverless Framework
,
1

Please note that normal messages are being send to stderr which causes Azure pipelines to fail.It shows ##[error] for lines that are not errors.

See example of output below

Deploying Kizi-Accounts to stage kizidev (eu-west-1)
Tracing DISABLED for function “Kizi-Accounts-kizidev-PreSignUp”
Tracing DISABLED for function “Kizi-Accounts-kizidev-PostConfirmation”
Tracing DISABLED for function “Kizi-Accounts-kizidev-LinkCustomerToAccount”
:heavy_check_mark: Service deployed to stack Kizi-Accounts-kizidev (78s)
functions:
PreSignUp: Kizi-Accounts-kizidev-PreSignUp (7 MB)
PostConfirmation: Kizi-Accounts-kizidev-PostConfirmation (7 MB)
LinkCustomerToAccount: Kizi-Accounts-kizidev-LinkCustomerToAccount (7 MB)
##[error]Bash wrote one or more lines to the standard error stream.
##[error]
##[error]Deploying Kizi-Accounts to stage kizidev (eu-west-1)
##[error]Tracing DISABLED for function “Kizi-Accounts-kizidev-PreSignUp”
##[error]Tracing DISABLED for function “Kizi-Accounts-kizidev-PostConfirmation”
Tracing DISABLED for function “Kizi-Accounts-kizidev-LinkCustomerToAccount”
##[error]
##[error]:heavy_check_mark: Service deployed to stack Kizi-Accounts-kizidev (78s)

2

What do you mean by “normal” messages? What exactly is problematic here?

3

Non error message are displayed as errors instead of warnings etc.This causes pipeline builds to fail because it thinks errors occurred

4

The log outputs are redirected to stderr which is a standard practice for CLI tools - it’s a change from how it behaved in v2 along with new logs.

5

That doesn’t sound right,stderr stands for standard error.Its not errors being logged

6

stderr is the standard output to which logs, errors, diagnostic messages are outputted by most of the CLI tools and programs. It wasn’t the case in Serverless for a long time due to messy implementation of the logging engine, that has been changed in v3. Even if the name of stderr might suggest that it’s only for errors, that is not the case.

I believe you might’ve explicitly enabled failing on stderr output in Azure Pipelines - you should be able to turn it off in a similar way as suggested here: Azure command-line task - What is the difference between 'Fail on standard error' and 'Continue on error (unchecked)'? - Stack Overflow

7

Thanks for the quick feedback but I must disagree with you , stdout should be used for normal logs. It makes no sense whatsoever to use the error function to log non error messages while there is a stdout function to stream normal messages. Do you have a link where I can read this CLI standards because its basic Linux commands and practices?

8

Hello, you can find more details about our current logging/output APIs - utils/log.md at main · serverless/utils · GitHub

There’s a distinction between substantial output that is intended for further processing - for that we use writeText and that is being outputted to stdout, whereas everything else is considered to be logs/diagnositcs and that is outputted to stderr. It’s done on purpose to allow more programmatic use of certain commands and allow e.g. deterministic parsing of command outputs that are no longer polluted with warning/logs.

1 Like
9

it’s a change from how it behaved in v2 along with new logs.
Nox Vidmate

10

It surprises me too… I just updated to v3 version and all my pipelines are broken now. Fortunately, I found this topic and wasted only a few days.

The problem is that “serverless deploy” usually is just one of a ton of commands in a deployment script. Of course, It’s possible to ignore the whole stderr, but in this case, you will miss a really important mistake sometime.

So, I think this “feature” should be added to the list of breaking changes…

11

Yep also seeing this issue with serverless causing my pipeline (Octopus) to fail due to output in stderr. Other CLI’s do not give me this issue unless there is a genuine error.

My work round seems to be ignore stderr in my pipeline which seems a step backwards :frowning: