Plugin parameter "Logging verbosity" lacks documentation

[konste]

The last parameter on the Bazel build step page is Logging verbosity which may take values:

• Default
• Quiet
• Normal
• Verbose
• Detailed
• Diagnostic

Unfortunately, there is no information on how those values get translated to Bazel build parameters (if they do) or what exactly kind of the output filtering each of the values provides. We need that information to figure which verbosity level would provide us with the most detailed info for the failing tests while keeping the rest relatively compact.

[NikolayPianikov]

@konste These values are not translated to Bazel commands. TeamCity logger is listening all events and sends to TeamCity just a part of information depending on a severity level. I can suggest to use more detailed logging at the first "Setup" stage for some new project or when you are investigating some issue and Default or Quite mode in other cases. If your want to report some issue to our bug tracker you could use the Diagnostic mode. TeamCity logger sends raw messages to together with produced messages in this mode. For instance this code creates a message to send to TeamCity depending on a Verbosity level.

[NikolayPianikov]

@konste It would also be great if you could suggest any improvements there.

[konste]

It is not obvious how to design this feature better. I will try to list some ideas, though.

Now we need to adjust the desired verbosity of console output separately (using Bazel options) and then adjust the verbosity of the log in TeamCity separately (using adding settings). This is double work. As the one possible logging mode, I would let addin to just pass stdout and stderr through - to TeamCity log, so that it looks exactly like console output. We can turn off cursor movement functions in Bazel for TeamCity.

Log verbosity Default - what does it mean?

Other than Default there are five verbosity levels, and it feels excessive. I would reduce it to four, like in Visual Studio: Minimal, Normal, Detailed, Diagnostic. Or maybe even three - Minimal, Normal, Full.

I will do some experiments, collect and compare the logs with the different verbosity settings and provide more input for you.

[NikolayPianikov]

@konste thanks for the detailed answer.

Bazel's command line argument --logging does not affect the verbosity in TeamCity, because Bazel always dispatches the same set of events. Unfortunately, the approach Bazel uses --logging - is not that obvious, so I didn't spend a lot of time on their equality. It took me about a month to make the build log equal to MSBuild. About using stdOut and stdError. The TeamCity logger handles events from Bazel and does a lot of things, for example:

• analyze and publish warnings, errors and build problems
• supports blocks to make the build log more compact (structured build log)
• Supports real-time test results

If we were to use stdOut instead of the above approach, we would run into several problems:

• errors, warnings and build issues are not highlighted correctly or they are out of sync with stdOut and it would look like a complete mess
• no way to maintain a structured build log
• test results are not synchronized with stdOut, for example, information about failed tests appears in unpredictable places along with stdOut

The Default level is now actually the Normal level. There are too many log levels, I agree. I look forward to the results of your experiments.

[konste]

At this time we are getting ready to ship V1 of our Bazel build rework. We cranked build verbosity all the way up to Diagnostic because лучше перебдеть чем недобдеть and I have to postpone the experiments with verbosity, but I will get back to it eventually.