Sonar-scanner Version
Lorin Cupples
The SonarScanner does not yet officially support ARM architecture. Still, early adopters reported it is working fine. If you encounter problems, don't hesitate to share your experience with us on the SonarQube or SonarCloud Community Forum but keep in mind that there is no support at this time.
When running the container you have to make sure the user 1000 has read and write access to the directories you are mounting (like your source code or scanner cache directory), otherwise you may encounter permission-related problems.
To prevent SonarScanner from re-downloading language analyzers each time you run a scan, you can mount a directory where the scanner stores the downloads so that the downloads are reused between scanner runs. On some CI systems, you also need to add this directory to your CI cache configuration.
If the files to be analyzed are not in the directory where the analysis starts from, use the sonar.projectBaseDir property to move analysis to a different directory. E.g. analysis begins from jenkins/jobs/myjob/workspace but the files to be analyzed are in ftpdrop/cobol/project1. This is configured in sonar-project.properties as follows:
If your SonarQube server is configured with HTTPS and a self-signed certificate then you must add the self-signed certificate to the trusted CA certificates of the SonarScanner. In addition, if mutual TLS is used then you must define the access to the client certificate at the SonarScanner level.
Unsupported major.minor version
Install the last version of SonarScanner CLI (from version 6.0, no JRE installation is required). Otherwise, upgrade the version of Java being used for analysis or use one of the native package (that embed its own Java runtime).
Property missing: 'sonar.cs.analyzer.projectOutPaths'. No protobuf files will be loaded for this project.
Scanner CLI is not able to analyze .NET projects. Please, use the SonarScanner for .NET. If you are running the SonarScanner for .NET, ensure that you are not hitting a known limitation.
The pages you replied with do not say how to update SonarQubeAnalyze@5 task to use a different version of the scanner. So can the SonarQubeAnalyze@5 task be configured to use the 5.8.0 scanner ? and if so how can that be done please ?
The SonarQube Extension for Azure DevOps contains the Scanner for .NET 5.8.0 , which has an embedded SonarScanner version 4.7.0.2747. You can read Introduction to the SonarQube/SonarCloud .NET analysis to get a better understanding of what each component does.
So between SonarQubePrepare and SonarQubePublish, you need to build and also to run the tests in order to have the code coverage report. See this example (SonarCloudPrepare and SonarQubePrepare are essentially the same steps).
Having said that, I do believe we can improve our existing documentation, as it is not clear from the YML example file what you need to fill in between SonarQubePrepare and SonarQubePublish. I will send this feedback to our documentation team.
" The SonarScanner for Ant is an Ant Task that is a wrapper of SonarScanner, which works by invoking SonarScanner and passing to it all properties named following a sonar.* convention. This has the downside of not being very Ant-y, but the upside of providing instant availability of any new analysis parameter introduced by a new version of SonarQube. Therefore, successful use of the SonarScanner for Ant requires strict adherence to the property names shown below."
I am trying to analyze my source code using SonarQube. I am trying to use sonar-scanner as my tool to run analysis from command line. I followed the guidelines presented in this documentation article: +with+SonarQube+Scanner
From the error it looks like its not finding the right version for JAVA/JRE to run the cli tool. My understanding was that the tool should work with any Java 1.7+ version. I am using Oracle JDK 1.7.0_55. I also tried using OpenJDK 1.8 but I am still getting the same error. I also checked my JAVA_HOME variable is set to the right JDK directory.
After Struggling with this for a while, I found the cause of the problem. The CLI is looking at your JAVA_HOME path variable to figure out the version of Java it needs to use. even tough the default java and javac commands were pointing to JDK 8, setting the JAVA_HOME environment variable to your JDK 8 root directory solved the issue.
Thanks for your response and help. We are currently using SonarQube 6.7.3 (the previous LTE), Bamboo 6.7.3, scanner 2.8. Not sure when will we upgrade Sonarqube 7.9.1(current LTE). Will the curent versions work perfectly? Or you recommend upgrade scanner to 4.0?
what are you trying to achieve:
I need a stable way to retrieve binaries from Sonar (now mainly limited to Sonar Scanner and Sonar Scanner for .Net, as the plugins are now part of the platform). We were used to implementing a remote repository pointing to , but this location seems to miss some binaries (no Sonar Scanner for .Net 5.x there, for example)
Are you still pushing binaries there, or are you using only github binary distribution for new versions?
Thanks, this is the location I was used to using (via my internal proxy server).
But if you get there, you will not find Sonar Scanner for .Net (version 5.x branch of the Sonar Scanner for MSBuild), the latest available there is Sonar Scanner for MSBuild 4.7. This is why I am raising this question, basically.
It is important to make sure that the SonarScanner $install_directory/bin location is added to the system $PATH environment variable. This will ensure that sonar-scanner command will be resolved by the customScanner, and prevent the error:
I am having issues with the Gradle using sonar-scanner-gradle v3.4.0.2513 and Gradle v7.5.1. Our project installs nodejs into a sandbox path, and we are attempting to configure Sonar to use the binary path set via the sonar.nodejs.executable propert. Without fail we always get Error when running: 'node -v'. Is Node.js available during analysis?.
What is surprising is that when we look at the scanner context, we can see that the value is set properly with the correct path, and I have validated that the binary and path has the correct permissions to be executed. I have tried many different ways to set this, using subprojects and allprojects to add the sonarqube block containing the following:
I was looking at the node plugin code on github and found a debug line which might prove out that the property value is not being respected. I ran ./gradlew --debug sonarqube and this is the output from the debug line:
I tested the same configuration that you did and it works fine on my side. May I ask you to share your full analysis logs in debug mode? Also, which OS is it running on?
The idea is to understand what the JavaScript/TypeScript sensors are doing to create the node command and at which point it fails.
SonarSource have officially released SonarQube C# Plugin 4.4 and version 1.1 of the SonarQube Scanner for MSBuild. There have been no updates to the scanner documentation in this release, other that updating the version number to make it clear they relate to version 1.1 of the SonarQube Scanner for MSBuild.
When the analysis is carried out in post-build phase the code files are analyzed one at a time so the analysis rules are only ever looking at incomplete sections of code. As a result, there may be errors that cannot be detected, or there may be false positives returned for partial classes that are split across multiple files. Carrying out the analysis during the build phase improves the accuracy by allowing the diagnostic rules to assess all of the code in the project at once. It also means that the results will be consistent with those for the same SonarLint rules when run in the IDE.
If you are building using MSBuild 12.0 then there will be no change to the existing behavior; the SonarLint rules will continue to be run post-build. However, the C# plugin will warn you that you can get better analysis results by switching to MSBuild 14.0.
The reason the SonarLint rules can be run as part of the build in MSBuild 14 is that they are written as Roslyn analyzers, and the standard MSBuild 14.0 targets support executing Roslyn analyzers as part of the compile task.
The Roslyn framework has made it much simpler to write new analysis rules, and new analyzers are being created both by Microsoft and by the community. Consequently, we want to be able to run any Roslyn analyzer during the build and upload the issues to SonarQube, not just the SonarLint rules. The SonarQube Scanner for MSBuild v1.1/C# plugin v4.4 releases are the first step to being able to do this.
Fully supporting any Roslyn analyzer will require further changes to both the scanner and C# plugin. However, it will also require some work to be done for each analyzer that is to be integrated into SonarQube. The diagram below gives an overview of what is required:
New rules can be added to SonarQube by writing plugins in Java, whereas Roslyn analyzers are written in managed code. Fortunately, there is a reasonably close mapping between Roslyn analyzer rules and SonarQube rules.
As ever, we welcome comments and feedback. If you have a support question, head over to StackOverflow and have a look at the questions tagged with sonarqube and msbuild to see if there is already a solution there, and if not, please ask. Bugs can be reported via the SonarQube Google Group.
The previous SonarQube 7.9 LTS introduced code security features Security Vulnerabilities and Security Hotspots. Both have been vastly expanded in this release, including but not limited to:
Expanded security reports are available for Enterprise and Data Center editions of SonarQube: reporting now includes both CWE Top 25 2019 and CWE Top 25 2020 with a possibility of exporting a PDF document of the top reports.
The project home page now emphasizes quality and security of New Code. A full overview of the whole codebase of the project is still available in the Overall Code view, and all the other project details can be found tucked away in the separate Project Information section.
c80f0f1006