opened
mdwhitten
username_0
I would like to be able to see the individual warnings per file, which seems to be possible based on the screenshot in [WarningsPolicy.md](https://github.com/MicrosoftPremier/VstsExtensions/blob/master/BuildQualityChecks/en-US/WarningsPolicy.md). However, all of my warnings appear as "Unknown File": 
![image](https://user-images.githubusercontent.com/47825680/60977150-8f375980-a2f4-11e9-9edc-3b13f0fb97cb.png)

The log is being published to VSTS using the syntax`##vso[task.logissue type=warning;sourcepath=$messageFilePath;]$outputMessage"`. Hence, the file path is being published as a part of the warning (see below), but doesn't seem that it is being picked up by the task.

![image](https://user-images.githubusercontent.com/47825680/60977477-29979d00-a2f5-11e9-9f0d-1468c74e1df8.png)

I've attached the log for more context:
[log_21_154154.zip](https://github.com/MicrosoftPremier/VstsExtensions/files/3377977/log_21_154154.zip)

Thanks!
Warnings report shows warnings as "unknown file"
issue
created
mdwhitten
username_0
However, I had hoped that if I at least formatted my warning in the proper way, it would be picked up and reported in the same way as the MSBuild tasks.
comment
created
ReneSchumacher
username_1
Hi Michael,

sorry for letting you down, but we only run the proper analysis on logs created by one of the MSBuild-based tasks (VS Build, MSBuild) or the StyleCop task. Thus, it doesn't matter how you format your log output, the analysis logic will never pick up those log lines.

However, it looks like you're using a standard tool (TestStand from National Instruments) to run some kind of static analysis (I haven't spent too much time skimming through their website). I assume there is no direct support for Azure DevOps from their end, right? I'm wondering if it might be worth investing a bit in creating a "standard" task for running this analysis that properly logs warnings and errors as real build issues (this would get rid of the need of custom warning filters to pick up those warnings) and then adding support for the resulting log file to the Build Quality Checks task. Especially if you'd be willing to share your parsing script and information about how to properly run the analysis. :)

René
comment
created
mdwhitten
username_0
Because of the above, I am **not using any warning filters**. Rather, I am using the [Azure Pipelines Logging Commands](https://github.com/microsoft/azure-pipelines-tasks/blob/master/docs/authoring/commands.md) to log the errors and warnings so that they show up as warnings and errors in the build summary in Azure. Is this what you mean by *properly log[ing] warnings and errors as real build issues*"? 

As best as I can tell, MSBuild and other tasks utilize the exact same command syntax to output their build warnings to the console, specifying which file rendered the warning using the `sourcepath` flag. I am doing the same thing in my logging above. Hence, this is the reason that I was surprised that the task does not pickup the file included with the warnings, since I think I am logging these the proper way.

What are your thoughts? Thanks again for your support!
comment
created
gerwinjansen
username_2
What is 'logs'? Is that the stdout/stderr or separate files? Can you explain how BuildQualityChecks works? Why can it detect warnings-including-sourcepaths for MSBuild-based tasks but only raw warnings for every other task? The raw-warning contains all the information that is needed.
And even for MSBuild-based tasks it does not display the linenumber and columnnumber.
comment
created
ReneSchumacher
username_1
Hi @username_2,

Build Quality Checks is not designed to display warnings created by other tasks. It's purpose is to simply count warnings and compare the current count with defined thresholds (either fixed value or the warning count from a previous build) to decide whether or not to break the build.

Every issues (warnings and errors) that is correctly logged by a task with the logging command you mentioned is displayed in the build summary automatically. That is the purpose of those logging commands. Thus, there's no need to repeat that information again which is the reason why we don't display any line or column information.

I believe that you are talking about the warning statistics. The purpose of those is to give a summary of warning changes in specific code files (or arbitrary files when using the warning file evaluation). So instead of listing all details for all warnings in a file, we just show files that have either more or less warnings compared to the previous build.

What are you expecting to see?

Btw: we only run statistics analysis for MSBuild and StyleCop since we parse the actual warnings from the tool itself, not the logging commands. This is because in the past logging commands were not written to the log file so there was no easy way to grab them. We could update our task to run a logging command analysis, but we'll have to think about backwards compatibility.
comment
created
ReneSchumacher
username_1
Hi @username_0,

first, I have to apologize that it took us so long to work on your feedback. It was sitting on our backlog but there was always something else to do. Good news is that we were able to create a generic solution now that works for all tasks or scripts that use our logging commands similar to what you do in your PowerShell script. Your files should now properly show up in the statistics section of the extension summary.

As this issue is resolved now I'm going to close it. Nevertheless, please feel free to add additional comments or open new issues if you still have problems getting statistics from your pipeline.

Happy building,
René
comment
closed
ReneSchumacher
username_1
issue
created
mdwhitten
username_0
That's great! Thank you for getting back to me and for creating the generic solution. I will happily use this in my pipelines now.
comment