Problem matcher does not work with normal verbosity

[Helco]

Description: When running dotnet build --verbosity normal no errors or warnings are detected by the problem matcher due to the diagnostic lines beginning with whitespace.

E.g. /home/runner/work/zzio/zzio/zzio/zzre/Program.cs(56,23): error CS1503: Argument 1: cannot convert from 'zzre.ITagContainer' to 'System.CommandLine.Invocation.InvocationContext' [/home/runner/work/zzio/zzio/zzio/zzre/zzre.csproj] is detected, but

/home/runner/work/zzio/zzio/zzio/zzre/Program.cs(56,23): error CS1503: Argument 1: cannot convert from 'zzre.ITagContainer' to 'System.CommandLine.Invocation.InvocationContext' [/home/runner/work/zzio/zzio/zzio/zzre/zzre.csproj] is not detected.

Task version: v3

Platform:

• [x] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [x] Hosted
• [ ] Self-hosted

Repro steps:

• Create csharp project with syntax error
• Create GitHub action with setup-dotnet and a dotnet build --verbosity normal
• Run the action

Example run

Expected behavior: Diagnostics in the build output should be matched and annotations created

Actual behavior: Diagnostic output is ignored.

[aparnajyothi-y]

Hello @Helco, Thank you for creating this issue and we will get to you once we found the root cause :)

[aparnajyothi-y]

Hello @Helco, Thank you once again for creating the issue. We have investigated the issue and found that the configuration that is given for problemMatcher is any line that does not start with a whitespace as per the current implementation. We are working to accommodate the lines that begin with whitespace. There are few work around

1. by adjusting the regular expression used in the problem matcher to match the output format produced by dotnet build --verbosity normal. Below is the sample code to use.

   run: | dotnet build --verbosity normal | sed 's/^ *//' > build.log

   • name: Parse build output uses: actions/parse@v1.0.0 with: path: build.log matcher: problemMatcher.json

2. we could add a step in your workflow that modifies the build output to a format that the problem matcher can recognize.

[rainersigwald]

Another option you might consider though is to log to the console at minimal verbosity but also capture a binary log (https://aka.ms/msbuild/binlog) and upload it as an artifact (pass or fail). That has more information than "normal" and when used with the viewer (https://msbuildlog.com) is usually easier to understand.

The default problem matcher should definitely be changed to work here, though.

(@baronfel you'll want to see this issue)

[Helco]

Thanks for your answers, I will definitely take a look at the binary logs, they look useful for a number of MSBuild tasks :)

For the problem matcher I just added a fixed problem matcher after calling the setup-dotnet action, you can find it here: https://github.com/Helco/zzio/blob/master/.github/csc.json

[aparnajyothi-y]

Hi @Helco, thanks for confirming that the issue was resolved with problem matcher. We'll review this solution and consider updating the problem matcher to accommodate other configurations as needed.