Standard CDK log messages are written to the StandardError stream

[DamirAinullin]

Standard default CDK log messages are written to the StandardError stream. We can't disable these log messages.

Environment

• **CLI Version :1.36.1
• **Framework Version:1.36.1
• **OS :Windows 10
• **Language :Typescript

Other

These log messages lead to failure of AzureDevops Build:

I think that the problem is here:

aws-cdk/packages/aws-cdk/lib/logging.ts

Line 29 in 986e281

export const print = logger(stderr);

In my opinion it is not good practice to write some non-error logs in stderr. And on top of all that we can't disable these default log messages.
--no-color option doesn't help. Setting options --trace --verbose as false does not disable default log messages.

---

This is 🐛 Bug Report

[DamirAinullin]

Or at least give us possibility to disable default log messages.

[shivlaks]

@DamirAinullin - These were initially writing to the console rather than stderr/stdout and IIRC it was changed to improve the color experience (#5250)

I also think it's reasonable to have a switch to turn off logging, which does not currently exist.

I've been looking into alternatives to our current logging as I would like to switch off it.
Ideally we would also like to be able to log to a default location (or designated location) - i.e. something like cdk.log or equivalent as well as the console. The logging solution should also allow for switches to turn off. Are there any other things you'd like to see in terms of logging experience?

[DamirAinullin]

No, it just would be great to have ability not to write logs to the StandardError stream.

[marcindulak]

A nice thing to have would be a possibility of logging to stdout/stderr and file and the same time, and having those logging levels configurable separately. See ansible/ansible#38786

[marcindulak]

Just another idea, if the logging system gets redesigned: it would be helpful to log json.

[shivlaks]

@marcindulak I do want to rewrite the logging to be a little more pragmatic now that we've collected more use cases and pain points.

I also think it's a reasonable short term ask to add a flag to disable it to unblock use cases as the one mentioned by @DamirAinullin

[DamirAinullin]

@shivlaks do you have any updates about this issue?

[weschan]

Hi all, I was struggling with this as well looks like as part of #9516 and CDK version 1.60. You can now use a environment variable "CI" set to any value. This will change the logging behavior and appears to use stdout and therefore fixes the issue with CI/CD tooling reporting back in an error state.

[joel100]

@weschan I've tested that in 1.61.1 and this doesn't seem to work. It also seems to be a bad band aid. For auditing and traceability it seems desirable to see what changes are being applied.

Fundamentally only errors should be written to stderr. What's the underlying reason output is written there rather than stdout?

@shivlaks can this be bumped in priority? Understand this might have upstream issues, but it makes it difficult to do anything programmatically against output with CI/CD tooling while it's returning through stderr.

[antonfelich]

I've tried the "CI" variable as @joel100 did with version 1.75.0 and it doesn't seem to work for me either (unless I'm doing something wrong).

It definitely sucks having the CI/CD server thinking everything has failed, when in actual fact it's fine.

Looks like you were recently assigned @rix0rrr does that mean we might see some movement soon? 🤞

[triandco]

Any update on this please?

[mtheoryx]

As of v1.125.0, even using the --ci option for deploy, it still appears to be logging to STDERR and failing in Azure pipelines.

[blimmer]

I wanted to weigh in on this one with my use case as well. I'm currently using lerna + yarn workspaces to deploy a complex CDK application. I have a little CI script that runs a cdk diff in all packages that have changed. Ideally, it would look like this:

yarn lerna run --since '' cdk -- diff

However, lerna does not output stderr unless there's a failure in the task (and I'm using aws-cdk:enableDiffNoFail to exit with a 0 exit code unless there's a legitimate failure during the diff process). See lerna/lerna#2199 for a lerna issue asking to expose stderr even without a failure.

So, instead, I have to run with a --stream flag and --concurrency 1 to see grouped diffs using lerna:

yarn lerna run --since '' --stream --concurrency 1 cdk -- diff 2>&1

This significantly slows down our build process because info messages are output to stderr. At the very least, being able to configure the default logging stream (from stderr to stdout) would be extremely helpful to work around this.

Looking a bit more into the code that handles diff, the problem's scope is even greater than just the default logger behavior. The diff command takes a stream parameter that's defaulted to process.stderr in two places:

1. On line 84:

   aws-cdk/packages/aws-cdk/lib/cdk-toolkit.ts

   Lines 79 to 84 in e2f2a97

   	public async diff(options: DiffOptions): Promise<number> {
   	const stacks = await this.selectStacksForDiff(options.stackNames, options.exclusively);
   	const strict = !!options.strict;
   	const contextLines = options.contextLines || 3;
   	const stream = options.stream || process.stderr;

2. On line 39:

   aws-cdk/packages/aws-cdk/lib/diff.ts

   Lines 36 to 40 in e2f2a97

   	if (!diff.isEmpty) {
   	cfnDiff.formatDifferences(stream || process.stderr, diff, buildLogicalToPathMap(newTemplate), context);
   	} else {
   	print(colors.green('There were no differences'));
   	}

   Also, print defaults to stderr:

   aws-cdk/packages/aws-cdk/lib/logging.ts

   Line 34 in e2f2a97

   export const print = logger(stderr);

I'm assuming this is why this ticket was tagged as "effort/large". In an ideal world, it feels like anything that writes out to the user via the console should go through logger, often defaulting to stdout instead of stderr.

[JayQuerido]

Going to add our use case as well. In our TeamCity jobs, we now have to add several custom failure conditions to each job that runs any CDK.

For example, we have checks for the following strings in our build logs:

• "Error:"
• "Since this app includes more than a single stack, specify which stacks to use"
• "failed to deploy"
• "CREATE_FAILED"
• "Stack failed:" (this one's possible because all our production stacks are named xxStack)
• "No stacks match the name(s)"
• ... more?? (we added the last 2 tonight after more false successful deployments)

Now multiply all these error conditions for each of our build and deployment jobs that use CDK. It's a maintenance problem.

Contrast this to every other CLI tool: I simply check the TeamCity box that fails the build if any output is written to STDERR.

This is causing false successful builds, and worse: false successful deployments. But the worst is that it's eroding trust in our build infrastructure. We can't predict all of the possible strings that indicate errors. Please, change the output to match every other CLI tool, and use the output streams as they were designed.

CDK team, I really wish your reason for doing this was more than "colors". You've gone against the fundamentals and it's causing legitimate pain for your users. It seems like you're prioritizing people who build and deploy manually from their local machine, rather than the teams using CI/automation.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.