##[error]ERROR: Error during SonarScanner execution
ERROR: Error during SonarScanner execution
##[error]java.lang.NullPointerException
java.lang.NullPointerException
##[error]at org.sonar.scanner.externalissue.ReportParser.validate(ReportParser.java:38)
at org.sonar.scanner.externalissue.ReportParser.parse(ReportParser.java:29)
at org.sonar.scanner.externalissue.ExternalIssuesImportSensor.execute(ExternalIssuesImportSensor.java:58)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:34)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:78)
at org.sonar.scanner.externalissue.ReportParser.validate(ReportParser.java:38)
at org.sonar.scanner.externalissue.ReportParser.parse(ReportParser.java:29)
at org.sonar.scanner.externalissue.ExternalIssuesImportSensor.execute(ExternalIssuesImportSensor.java:58)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:34)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:78)
Steps to reproduce
After the build and test cycle have successfully been completed. I’ve run a Powershell script that reads the build log and convert them into SonarCloud issues.
For each project I’ve created a placeholder json name “CSharpGuidelinesAnalyzer.json” with contains the following code:
{"issues": []}
The content of the json gets replaced when an issue was found in a specific project folder. So when an issue is found in $source\Project A. The issue will be written in the CSharpGuidelinesAnalyzer.json within that project folder. As the SonarScanner scans every folder invidually.
It looks from the properties you’re setting that you are mixing up two different scenarios:
generic issue importing, and
the special handling of issues from third-party Roslyn analyzers.
Scenario (1) is intended for third-party analysis tools that are not specifically supported. In that case, you are responsible for configuring and executing the analysis tool, then creating an issues file in the expected format.
In this scenario, the sonar.cs.roslyn.XXX properties are irrelevant - only the sonar.externalIssuesReportPaths property matters.
Scenario (2) is specific to issues raised by Roslyn analyzers. You can add third-party Roslyn analyzers to your MSBuild projects and configure them using rulesets as normal. The SonarScanner for MSBuild will then automatically run those analyzers and upload the issues to SonarQube as external issues. You don’t need to manually produce a .json file and the sonar.externalIssuesReportPaths property is irrelevant.
The sonar.cs.roslyn.XXX properties give you some control over how the issues raised by the third-party analyzers are categorized. See the documentation for more information.
Are the issues you are trying to upload produced by a Roslyn analyzer, or by something else?
I’m indeed trying to upload issues raised by a third party Roslyn analyzer. To be specific, this is the one I’m using CSharp Guidelines Analyzer. The only problem is that the default functionality doesn’t seem to import the issues generated by the Roslyn analyzer. Any idea how to debug this?
Therfore I’m trying to go the custom direction and created the json myself. As shown in the documentation. As the issues are generated in the custom json file, also those issues are not shown in SonarCloud. So what am I doing wrong here?
I would like to go with scenario 2 as this is the more generic way to work with SonarCloud. It also doesn’t involve relying on custom code. As I understand the documentation correctly, I’ve made the following changes.
Debugging:
Debugging what is happening on a CI build agent is easier if you have access to the build agent machine so you can look at the files that are produced during the build. If you don’t, here are some things you can check without access to the machine:
check that issues from the SonarC# analyzer are being reported correctly. If necessary, create a new issue in the code - just adding // TODO will trigger S1135 which should be on by default.
If “normal” SonarC# issues are being reported then the basic end-to-end process is working correctly.
check for any warnings in the CI build output log
also in the CI build output log, check the parameters passed to csc.exe. They should include the csharpguidelinesanalyzer dll, passed as an /analyzer.
If it doesn’t, then check your project is correctly configured to include the analyzer as a NuGet package.
If you do have access to the build machine, have a look in the Roslyn error log files to see if they contain the issues you expect. You can find the names and locations of the error log files by looking at the arguments to csc.exe. They will look something like the following: /errorlog:D:\a\1\s\src\Core\bin\Release\net46\SonarLint.VisualStudio.Core.dll.RoslynCA.json
If you don’t have access to the build machine you can add build steps to find and publish those ‘.json’ files so you can look at them. Another alternative is to run the analysis locally on your own machine using the SonarScanner for MSBuild. The RoslynCS.json files will be produce as part of the MSBuild phase.
One thing I noticed is that the issue for “AV2210 - Build with -warnaserror” was not uploaded. My guess is that this is because it does not have any information about the location of the issue. However, in that case I would have expected it to be reported as a Sonar project-level issue.
Nice to see, that you’ve got it working. One thing that I see is a major difference between our solution, is that you are running on .NET Framework 4.6.x, my solution on the other hand is a .NET Core 3.1 solution.
So what I did yesterday. I’ve created a local self-hosted agent for Azure DevOps. This way I can actually view the build output of the files locally.
This is actually working. SonarCloud shows me the Sxxxx errors from the SonarCloud analyzer. I see the issues in my report. This has always worked.
Yes, I also see all the build warnings with the appropriate AVxxxx issues in the build log.
I scanned the log files, but couldn’t find any reference to CSC other then the build warning. Any idea on where to find this?
I do find all the *RoslynCA.json files. Each file containing one or more issues from the csharpguidelinesanalyzer. So still not sure why this issues are taken into SonarCloud.
One thing that I did found, was that the ruleset merged.ruleset doesn’t contain the rules from the csharpguidelinesanalyzer. Could that be an issue?
csc.exe is the C# compiler. It’s called as part of the MSBuild step, and it should appear in the “normal” verbosity Azure DevOps log. However, since you can see AVxxxx issues in the output that means the analyzer is being passed to the compiler correctly.
merged.ruleset should contain the settings specified in your ruleset, combined with the ruleset generated from the Quality Profile. However, it a Roslyn rule doesn’t appear in the ruleset then the compiler will use the default enabled/disabled status and severity for the rule. The fact that you can see AVxxxx issues in the console output means the rules are being run. If the rules are being run then any issues they produce should be uploaded.
Do the AVxxxx issues in the RoslynCA.json files have location data?
In the bin folder I can see *i.dll.RoslynCA.json files. The files contain both AVxxxx and Sxxxx issues. So the custom analyzer and the Sonar Analyzer are both working. The only problem is, that they aren’t uploaded to the report.
AVxxxx
{
"ruleId": "AV1008",
"level": "note",
"message": "Class 'Headers' should be non-static or its name should be suffixed with 'Extensions'.",
"locations": [
{
"resultFile": {
"uri": "file:///D:/agent/_work/1/s/F2MPL.Api/Constants/ConfigurationConstants.cs",
"region": {
"startLine": 5,
"startColumn": 29,
"endLine": 5,
"endColumn": 36
}
}
}
],
"properties": {
"warningLevel": 1
}
},
Sxxx
"S4823": {
"id": "S4823",
"shortDescription": "Using command line arguments is security-sensitive",
"fullDescription": "Using command line arguments is security-sensitive. It has led in the past to the following vulnerabilities:",
"defaultLevel": "warning",
"helpUri": "https://rules.sonarsource.com/csharp/RSPEC-4823",
"properties": {
"category": "Critical Security Hotspot",
"isEnabledByDefault": true,
"tags": [
"C#",
"SonarWay",
"MainSourceScope",
"NotConfigurable"
]
}
}
As I look closer to the error, the structure of the output between the two issues raised is completly different. Could that perhaps be a problem?
You are comparing data in different sections of the .json file.
your JSON snippet for “AV1008” is from the results section which contains the issues that have detected.
your JSON snippet for “S4823” is from the rules section which contains a description of the rule.
The detailed log output for the end step in your pipeline will contain output describing the processing of the Roslyn output files. Check for any warnings or hints about why those issues (or perhaps entire files) are not being processed.
I’ve taken another look at the *.RoslynCA.json and it looks you’re right. Copied the sources from different places. When looking at the JSON, the issues from SonarCloud and the custom analyzer seems to be using the same format.
With the detailed log output end step, you mean the “Run Code Analysis” step? I’ve added the log from that step. Run Code Analysis.txt (1.3 MB)
In the document I’ve found the following debug statements: 2020-05-29T06:21:58.7736605Z 08:21:58.773 DEBUG: 'Import external issues report' skipped because one of the required properties is missing
Don’t know if that is what I’m looking for… Do you have any ideas from the log file @duncanp
No, that’s not relevant here. It refers to the generic importing of non-Roslyn issues.
I can’t see anything obviously wrong from the log file. The log says 26 Roslyn reports were processed, but doesn’t provide any more information.
Can you create a simple project that you can share that reproduces the problem? Alternatively, you could try my reproducer that I shared in the zip file above to see what results you get with that.
@duncanp finally had the time to test your project. It seems that the basics work. Haven’t figured out why the existing project doesn’t work, but a new one does.
For now it’s good to know and see that it actually works.