terminal logger not that usable in practise

[rmannibucau]

Hi,

I really like the terminal logger feature but it has a big pitfall, it breaks all the outputs by default which means any failing build needs to run without it more or less.

What would be neat is to keep the terminal logger feature AND the output.
One way is to "split" the output in two parts, the build output (at the top for ex) and the "dynamic" output (tl) at the bottom - think gradle does it or was doing it at least.
An alternative is what maven daemon does (once well configured), ie assign N lines (N >= 1) per project, have the first line being the terminal logger and the other lines the build output of this project. Finally you stack the projects and you get an in between feedback.
Last option is to just dump the output on failure (capturing in a file during the build for ex).

Hope it makes sense

[baronfel]

Hi @rmannibucau - thank you for taking the time to provide feedback on the Terminal Logger. I have a few questions I'm hoping you can clarify:

it breaks all the outputs by default which means any failing build needs to run without it more or less

Can you clarify what you mean by this? What about the outputs is breaking in your view? Why do failing builds specifically need to run without the new mode?

Broadly, we do think of the TL output in two forms, much like you described already:

• static, per-project diagnostics and outputs - these are emitted as each project completes its build
• dynamic, per-msbuild-node data - this is 'live' and constantly updating with the state of the build

In the past we've tried your N-per-project idea and that quickly consumes all of the available terminal space because in .NET a user-facing project isn't the same as a 'project' to MSBuild - each TFM of a multi-TFM project is a separate project with separate outputs/diagnostics for example. This means that even a small repo (~5 projects) can quickly consume all of the space available in the terminal. So we've definitely struggled finding a balance here.

[rmannibucau]

What about the outputs is breaking in your view? Why do failing builds specifically need to run without the new mode?

Assume I have a multiproject solution and one test of a "middle" project fails, then the end output will not mention the project or the failing test.
When using ASP.Net with kind of access log (request logging) - or any other kind of test using some systematic logging - it is really unreadable and having to either grep or use a file report is not as smooth as just checking the last lines of the output to see what failed and fix it.

This means that even a small repo (~5 projects) can quickly consume all of the space available in the terminal. So we've definitely struggled finding a balance here.

Well it is functional for gradle and maven, the trick is to have a limit and multiplex some space depending the activity but the highly important part is a proper final reporting more than the live view which is fancy but not that critical to my eyes.

[baronfel]

Ah, ok - so if I'm understanding you correctly, the painful missing piece is the final build summary. Is that correct? If so, we're tracking that in #10681 and would like to tackle it in an upcoming release.

[rmannibucau]

@baronfel yes, the "live" view can likely be better giving a bit more context for "slow builds" but it is less a blocker than the summary on my side.