search

KirillOsenkov / MSBuildStructuredLog

A logger for MSBuild that records a structured representation of executed targets, tasks, property and item values.
MIT License
1.46k stars 198 forks source link

Which task failed the build? #513

Closed AArnott closed 3 years ago

AArnott commented 3 years ago

In this binlog, the build failed, but no task emitted an error message. Is there a quick search I can do in the structured log viewer to find which task returned false, causing a build failure?

test_net472 (1).zip

image

KirillOsenkov commented 3 years ago

cc @nohwnd ;)

AArnott commented 3 years ago

FYI I learned that this line in the log seems to be the culprit:

The test source file "C:\a\1\s\bin\Tests\Microsoft.VisualStudio.Composition.Analyzers.Tests\Release\net472\Microsoft.VisualStudio.Composition.Analyzers.Tests.dll" provided was not found.

That assembly doesn't exist because the test project targets only netcoreapp3.1. I was using the dotnet test -f net472 switch on the solution level to run all tests that are applicable to that target framework, but evidently vstest fails when it encounters a test project that doesn't have a matching TFM. :(

I worked around it for now by specifying each specific project to run tests on, but this requires that I split one test step in Azure Pipelines into one for each applicable project, which is both more verbose and requires more maintenance.

nohwnd commented 3 years ago

@KirillOsenkov wink wink back at you. 😉 Adding this to my notes for a future redesign.

AArnott commented 3 years ago

The specific answer being test runner aside, does the binlog file and/or viewer provide a way to discover which task failed the build? It should, IMO.

KirillOsenkov commented 3 years ago

In a normal case, MSBuild will log an error when a task failed, but didn't log an error. So it would be obvious (the task with an error underneath).

But if someone uses Reflection to turn off this safeguard in MSBuild, then all bets are off. I doubt we should do anything here other than work with folks to remove their reflection hacks.

Of course we could log the task return value (true/false) and then allow searching for tasks that returned false, but that's almost equivalent to what MSBuild is already doing with AllowFailureWithoutError.

I did file an issue against MSBuild here: https://github.com/dotnet/msbuild/issues/6633

They should still at least log a message if not an error/warning, if the task failed but didn't log an error and AllowFailureWithoutError was set to true. That way one could simply search for that message to see where it was logged.

Let me know if you do feel we should implement something additional to what I mention above. I'm not against it, just questioning whether it'll be worth it given the circumstances.

KirillOsenkov commented 3 years ago

Closing since it's not a viewer bug.