Improve structure of output of failed commands
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
Currently, when an action fails during the build, the output of the failed command is mixed with Bazel status information:
```
...
INFO: Found 1 target...
ERROR: /home/fhenneke/git/bazel-gazelle/language/go/BUILD.bazel:15:11: GoCompilePkg language/go/go.a failed: (Exit 1): builder failed: error executing command bazel-out/k8-opt-exec-2B5CBBC6/bin/external/go_sdk/builder compilepkg -sdk external/go_sdk -installsuffix linux_amd64 -src language/go/bzlmod.go -src language/go/config.go -src language/go/constants.go ... (remaining 80 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
language/go/bzlmod.go:6:2: result declared but not used
compilepkg: error running subcommand external/go_sdk/pkg/tool/linux_amd64/compile: exit status 2
Target //language/go:go failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 7.574s, Critical Path: 0.78s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
```
The order and structure of the log output can certainly be improved. I would personally find this much cleaner if it read more like this:
```
...
INFO: Found 1 target...
ERROR: /home/fhenneke/git/bazel-gazelle/language/go/BUILD.bazel:15:11: GoCompilePkg language/go/go.a failed: (Exit 1): builder failed: error executing command bazel-out/k8-opt-exec-2B5CBBC6/bin/external/go_sdk/builder compilepkg -sdk external/go_sdk -installsuffix linux_amd64 -src language/go/bzlmod.go -src language/go/config.go -src language/go/constants.go ... (remaining 80 arguments skipped)
language/go/bzlmod.go:6:2: result declared but not used
compilepkg: error running subcommand external/go_sdk/pkg/tool/linux_amd64/compile: exit status 2
Target //language/go:go failed to build
Use --verbose_failures to see the command lines of failed build steps.
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Elapsed time: 7.574s, Critical Path: 0.78s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully
```
Since `--sandbox_debug` seems to effectively imply `--verbose_failures`, this could probably be improved further.
### What underlying problem are you trying to solve with this feature?
It should be clear to users which console output belongs to Bazel and which output belongs to the build tools invoked by Bazel.
### Which operating system are you running Bazel on?
Any
### What is the output of `bazel info release`?
5.2.0
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?
_No response_
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Research direction
Reproduce a failed Bazel build like the example, first comparing normal output with --sandbox_debug and --verbose_failures. No files or tests are named, so trace the command-output handling from the CLI entry point and determine how status and build-tool messages are ordered. Done means the two sources are clearly separated and the relationship between the two flags is resolved.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, cli, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100