I suppose the fix would go in https://github.com/jenkinsci/analysis-model/blob/v10.8.0/src/main/java/edu/hm/hafner/analysis/parser/MsBuildParser.java, but the regex pattern looks rather complex.

More references for MSBuild diagnostic formats:

• CanonicalError.cs parses a diagnostic of a tool, for processing within MSBuild.
• EventArgsFormatting.cs formats a diagnostic back to a string. This can also use the (line-line,col) format that was not mentioned in MSBuild / Visual Studio aware error messages and message formats.

So the whole set of location formats is:

• (line)
• (line,column)
• (line-endLine)
• (line,column-endColumn)
• (line-endLine,column)
• (line,column,endLine,endColumn)

MsBuildParser is currently able to parse the first two.

Hopefully, we sometimes get a volunteer to provide support for Sarif in the analysis-model project then we are not required to use this complex regexp anymore.

The Roslyn C# compiler can write diagnostics to a file in SARIF formats, but if there are problems with NuGet package dependencies or such, then the diagnostics do not come from the C# compiler and cannot take advantage of that feature. So you'd likely need the regexp anyway, unless the build is using a custom MSBuild logger that writes SARIF.

MS_BUILD_WARNING_PATTERN could perhaps be simplified if it only tried to recognize diagnostics emitted by MSBuild console loggers or file loggers. Why does it involve ANT_TASK; is that for scenarios where Ant runs MSBuild and further decorates its output?

Hello drulli I've modified the part of the regex separately (responsible for parsing line and col) and tested it to parse all the different possible combination of line and col (seems like it works). But If I put it in the existing regex it will only make things more complicated (in terms of code readability).

So, I was thinking if you have any idea on how to make the regex more readable and maintainable such that it will be easy to work the current one is just way too long.

What if we break down the pattern into several segments and try to parse different parts of the log with separate helper functions inside the "createIssue" method. What do you think about this approach? 

What are your thoughts on this?

Breaking it into several parts makes sense! I wonder if it makes sense to even split this parser into different classes? (As in Armcc parsers). Then we have a dedicated parser for each pattern?

I think the maintainability will be much better if we can at least subdivide the parsing into smaller steps! Do you want to make a first suggestion?

Thank You for your confirmation! Yeah, I agree with you on the dividing into different classes approach that you took with the Armcc parsers. We can definitely try that!

I will try to raise an initial PR during the weekend! If you have any suggestion please do share!

I am on holidays for one week now, so I cannot help in the next week.

That actually helps me too. Since, I'll be having my exams for a week (starting from a week later). So, we can work on this when we both are available.