Commands write to STDERR stream even when the command succeeds

[ashokm]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request 
[ ] Other... Please describe: 

Problem

We have an issue with the ask-cli breaking our CI/CD pipelines. It is due to [Warn] logs being written to STDERR.

We use the Alexa Skills Kit (ASK) CLI and the Alexa Skill Management API (SMAPI) command in our pipelines.
Although the command executes successfully, our pipeline task fails with:

##[error]Error: The process '/usr/bin/bash' failed because one or more lines were written to the STDERR stream

We have attempted to debug this to see what is being written to STDERR by adding the following to the end of the command, which will prepend "STDERROR: " to each line sent to STDERR.

2> >(while read line; do (>&2 echo "STDERROR: $line"); done)

This results in us seeing

STDERROR: [Warn]: This is an asynchronous operation. Check the progress using the following command: ask smapi get-skill-status --skill-id amzn1.ask.skill.<redacted> --resource interactionModel --profile __ENVIRONMENT_ASK_PROFILE__

According to the documentation (https://developer.amazon.com/en-US/docs/alexa/smapi/ask-cli-command-reference.html) we see the following information:

Most ASK CLI commands can be run in debug mode, by appending --debug to the command. The same results appear as when –debug is not specified, except that an additional debug message is displayed (sent to stderr) after the command finishes running.

This seems to be the issue. This additional debug message is written to STDERR, which is causing our pipeline task to fail as anything written to STDERR is seen as an error.

How can we resolve this? Are there any options we/you can add to the ASK CLI to not write this additional debug message to STDERR?

Note that this was also an issue with the Azure CLI (see Azure/azure-cli#10856) and they resolved this for users by adding in a --only-show-errors option.

Please advise us on what we can do to resolve this.

Request

If writing [Warn] logs to STDERR is the expected behavior for the ask-cli, can you consider adding an option to disable warnings being written to STDERR?

Your Environment and Context

• ask-cli version: v2.22.4

[RonWang]

Hey Ashok,

Thanks for your feature request, the current CLI experience is by design - ask-cli expects users to rely on the exit code to decide if the command execution is succeeded or not, and we use stderr for informative messages. But we didn't realize that this behavior should break the programmatic usage of the CLI. We will look at the example you provided, and try to provide a reasonable solution soon.

[RonWang]

Hey @ashokm checking back to this issue - sorry for waiting long - the warning message comes from https://github.com/alexa/ask-cli/blob/develop/lib/commands/smapi/smapi-command-handler.js#L146-L148 where the pattern is statusCode == 202 && header has "location".

This is a common scenario, and I think we can add a environmental variable to control the on and off of the hint display. Proposing ASK_SKIP_LOCATION_HEADER_HINT new environment variable. When you set as below the warning message will not show:

export ASK_SKIP_LOCATION_HEADER_HINT=true

[RonWang]

Also checked through the codebase for similar case, where
we expect the command to be CI/CD friendly && non-error message (like a warn) should be passed to stderr.

It turns out this case is the only case. Thus I think for now we can just deal with this case specifically, instead of introducing a general --only-show-error kinda solution.

[ashokm]

Adding a general --only-show-errors option would be great 🙏

[RonWang]

Hey @ashokm thanks for this request~ we will take your feedback when we revisit our logger class. Consider the header.location is the only warning message that CLI outputs, let's use the environment variable for now. Once similar pattern happens, we will definitely considering how to avoid showing warning messages. We will checkin the code and will also do a routine release by end of month for this feature. Thanks for your feedback~

[sam-goodwin]

@sjcomstock67 we should prioritize this quick fix for customers.

[ashokm]

Adding a general --only-show-errors option would be great 🙏
Has the ASK_SKIP_LOCATION_HEADER_HINT environment variable solution mentioned above been released?

[CamdenFoucht]

Closing this in favor of #432 as the pipeline failure fix has been released with the environment variable change.