Eric StJohn

> Updated the error pattern to correctly match the failure. previously this did match, which is why the tool wrote this Still with your changes we aren't getting the issue...

I see - seems like that happened after the search string was changed earlier today: This was working before - seems like the issue table insertion and PR linking is...

@riarenas can you help us figure out why build analysis isn't linking up this issue with build? You can see the failure it's trying to match in attempt 1 of...

I think for these build failures it would be good to try to match previous attempts, since in these cases engineers will often rerun the build -- since it's not...

It also looks like this task creates a process but doesn't redirect output, so that will further be lost logging. https://github.com/microsoft/vstest/blob/e6c198ca439603f0e81d723538894646032745f6/src/Microsoft.TestPlatform.Build/Tasks/VSTestForwardingApp.cs#L30-L51

Adding a ref-count to this. It would have been super useful for the recent bug we were chasing in 9.0 where it only reproduced in the build and not any...

I think that's a concern for logs from the official build machines already. I'm not sure we can say that build outputs from official builds will never have secrets -...

Perf wins - yeah. Avoid having to read crack open files & read metadata / version info to resolve the conflicts. I was thinking about this more and I wonder...

As others have mentioned this is normal compiler behavior when new namespaces are added. In this case it looks like compiler is seeing the added *internal* namespaces in the `Windows.Win32`...

Yeah, it has a lot of internals which is one of the reasons why we've been reluctant to adopt it in dotnet/runtime (that and our need to actually have different...