When the pipeline fails its hard to see errors

[davidfowl]

The errors are all cleaned up in the pipeline and we no longer see stack traces of output from other CLIs by default (they are usually debug). The problem is now that it's hard to know what to do when the pipeline fails because:

1. There's no output - We don't show outputs from failed CLI executed by by default. The worst offender being docker buildx.
2. We don't tell you what to try next - aspire do {step} --log-level debug. There's nothing that tells you to to do this.

[captainsafia]

There's no output - We don't show outputs from failed CLI executed by by default. The worst offender being docker buildx.

If we implement the ExecutablePipelineStep that we've been talking about that provides an easy wrapper around calling an executable on the local machine, we can probably centralize this. Our stderr handling is all over the place depending on who is calling ProcessUtils.Run but we can probably include a sane default that pipes all stderr to debug level logs.

The other challenge with executables is that our ability to provide good errors is limited by the errors the tool itself provides.

We don't tell you what to try next - aspire do {step} --log-level debug. There's nothing that tells you to to do this.

Perhaps a nice increment is to include a message about setting the log verbosity on the PIPELINE FAILED message?

[davidfowl]

If we implement the ExecutablePipelineStep that we've been talking about that provides an easy wrapper around calling an executable on the local machine, we can probably centralize this. Our stderr handling is all over the place depending on who is calling ProcessUtils.Run but we can probably include a sane default that pipes all stderr to debug level logs.

This was my thought as well. We might need to expose some minimal API to let people run code before the step completetes with various piece of state (exit code etc).

The other challenge with executables is that our ability to provide good errors is limited by the errors the tool itself provides.

That's why I am a bit torn on if we should spew it by default, but a combination of debug by default and telling users what to do when it does fail might help.