add quiet mode to bazel run

[ixdy]

Description of the problem / feature request:

bazel run always prints out a few INFO log messages before running the command, and there seems to be no way of suppressing that output.

For example, I want to suppress all of these INFO: lines when running the following in kuberentes/kubernetes:

$ bazel run  --show_result=0 --noshow_progress --noshow_loading_progress --logging=0 cmd/kubectl -- version --client
INFO: Analysed target //cmd/kubectl:kubectl (589 packages loaded).
INFO: Found 1 target...
INFO: Elapsed time: 79.858s, Critical Path: 39.71s

INFO: Running command line: bazel-bin/cmd/kubectl/linux_amd64_pure_stripped/kubectl version
Client Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.1096+05ae431ea0978e", GitCommit:"05ae431ea0978ee2fc0be91e5b9bc82feb97b3a2", GitTreeState:"clean", BuildDate:"2018-03-16T22:46:18Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Feature requests: what underlying problem are you trying to solve with this feature?

I'd like to be able to build and run binaries through bazel without any additional information being written to stderr/stdout, since the tool being run also prints to stderr/stdout.

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

release 0.11.1

Have you found anything relevant by searching the web?

Found a related discussion in https://groups.google.com/forum/#!topic/bazel-discuss/JVCotYRXeyk.
I couldn't find any feature requests filed after @ulfjack's last reply there.

[philwo]

Agree that this would be nice to have.

Realistically, I won't have time to work on this in the next months, even though this should not be a huge change.

@ixdy Is the --script_path flag a possible workaround for your usecase?

[jlisee]

@philwo to me it looks like a bug that the run command is not respecting the --logging flag. For example even with --logging=0, bazel run still produces INFO logging information. From looking at the code it appears we need more filtering options in the build event handler.

And for us --script_path is not really a work around because it does not force a rebuild. We are trying to go for a system where you don't explicitly build anything you always use a bazal command, but that is hampered by the noise generated here.

[ulfjack]

The --logging flag isn't related to the command-line output, but to internal logging.

…

On Tue, Sep 11, 2018 at 6:04 PM Joseph Lisee ***@***.***> wrote: @philwo <https://github.com/philwo> to me it looks like a bug that the run command not respecting the --logging flag <https://github.com/bazelbuild/bazel/blob/3c5a109/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java#L72>. For example even with --logging=0, bazel run still produces INFO logging information. From looking at the code <https://github.com/bazelbuild/bazel/blob/56d125b9a4c8bf9a18bb83e473bc07759c708087/src/main/java/com/google/devtools/build/lib/runtime/ExperimentalEventHandler.java> it appears we need more filtering options in the build event handler. And for us --script_path is not really a work around because it does not force a rebuild. We are trying to go for a system where you don't explicitly build anything you always use a bazal command, but that is hampered by the noise generated here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4867 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHA9YZIGv2lJPJj40hYv-3BaSfVpCmJ4ks5uZ98ggaJpZM4SuiR3> .

[atavakoliyext]

Have any new workarounds been found since last year for this?

[ulfjack]

$ bazel run --experimental_ui_limit_console_output=1 hello-world
Hello world

Unfortunately, it looks like setting it to 0 means no limit.

[jathu]

@ulfjack Is there a way to use experimental_ui_limit_console_output but still expect errors to be printed? I've also tried bazel run //:target > /dev/null without any luck

[ulfjack]

No, unfortunately not. It limits all output, not just info messages. Bazel 3.3.0 has commit 7c67d1d, which adds --ui_event_filters. Maybe try that?

[peter-db]

Hey, just wanted to share the option I've gone with to invoke CLI tools build via Bazel:

#!/usr/bin/env bash
bazel build //target:target &> /dev/null
bazel-bin/target:target $@

[bduffany]

Beware that @peter-db 's approach means you will lose args specified in the BUILD file. This might be fixed by adding a call to buildozer 'print args' //target:target and prepending those to the arguments there, but that approach doesn't work in 100% of cases (e.g. if a macro adds the args).

edit: a more complete fix is to use --script_path as mentioned earlier on in the thread:

#!/usr/bin/env bash
set -e
# Make a temp dir for this script.
tempdir="$(mktemp -d)"
# Generate a script containing the commands that bazel run *would* execute.
# Write build logs to a file (not the terminal), and if the build fails,
# *then* show the output from the file.
bazel run //foo --script_path="$tempdir/script.sh" &>"$tempdir/build.log" || {
  cat "$tempdir/build.log" >&2
  exit 1
}
# Run the script, forwarding extra args.
chmod +x "$tempdir/script.sh"
exec "$script" "$@"

[acecilia]

Seems like this issue is solved by ui_event_filters, no?

bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress ...

Related: #12831 (comment)

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[luispadron]

I feel like this is still not working correctly, if I set the following flags:

  --ui_event_filters=-info,-debug,-warning,-stderr,-stdout
  --noshow_progress
  --logging=0

I still see debug logs when the server is shutdown:

Starting local Bazel server and connecting to it...

[acecilia]

Yep, there are some logs still left (maybe that is the only one?)

[jacky8hyf]

I also occasionally see "Extracting Bazel installation...". Is there any way to suppress this log and "Starting local Bazel server and connecting to it..."?

I have the following:

common:silent --noshow_progress
common:silent --ui_event_filters=,+error,+fail
common:silent --show_result=0
common:silent --logging=0

[lberki]

Update: I'm cooking a change for this. It's Google-internal because it turns out that it requires quite a bit of refactoring in the client to suppress the Extracting Bazel installation... messages and we have one pretty annoying integration point at Google that uses the C++ code of the Bazel client.

The interface will be bazel --quiet <command> <command arguments>. This must be a startup option so that it can affect the Bazel client, and thus the "Extracting..." messages.

[iancha1992]

A fix for this issue has been included in Bazel 8.0.0 RC2. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=8.0.0rc2. Thanks!