I'm trying not to analyse test files with Sonarqube.
I have several Maven subprojects and the test files are under these paths:
subproject1/src/test/, subproject2/src/test/ and so on
I'm passing the following option from Maven:
-Dsonar.exclusion=src/test/**
However, the test files are still analysed.
I also tried:
-Dsonar.exclusions=**/src/test/**,**/test/*,subproject1/src/test/**,**/*Spec.scala
But issues are still raised on test code.
There is no property by the name sonar.exclusion. sonar.exclusions is a valid property, but it applies to source files. You're trying to exclude test files - and yes the scanners do make the distinction, especially for Maven projects.
You should use instead sonar.test.exclusions
If you want to omit only certain rules, you have two options:
remove the rule from your profile
use Administration > Analysis Scope > Ignore Issues on Multiple Criteria to turn the rule off for only a subset of files.
Related
am having a class, which is giving me sonar issues.
That is just a temporary class and I would ignore it in future sprints. How can I mark that particular class to be ignored from sonar analysis, as we have guidelines to commit code only if no sonar issues found.
Generally speaking you do have multiple options: (i assume you are using java, but there are equivalent solutions for other languages)
ignoring the whole class
There is a property called sonar.exclusion which you can set to ignore that specific class. This needs to be set either your sonar-project.properties or based on the scanner you are using. For details take a look here
ignoring just some lines with issues
In the java world you can use line comments with //NOSONAR <reason> to exclude lines from detection. There are equivalents in other languages too.
ignoring just some issues on the class/method
In Java you can use the #SuppressWarnings("<rule id>") to exclude issues from classes and methods for detection. see https://stackoverflow.com/a/30383335/3708208
Define multiple ignore criteria for wildcard and rules
you can also define special settings in sonarqube, to ignore special files and folders via wildcard input, and which rules should be ignored. see https://stackoverflow.com/a/53639382/3708208
for those who use SonarLint plugin for IntelliJ Idea:
File > Settings > Tools > SonarLint > File Exclusions
I exclude our JUnit test from the scanning, however, I would like for it to be scanned for certain set of rule, how can I configure SonarQube to do this?
The SonarQube documentation page Narrowing the focus allows you to specifically target some files for given set of rules. It probably can help you achieve what you want to do.
Now, the SonarJava analyzer already separates Main sources files from Test Source files. Correctly configured, your project will then apply only rules targeting tests on files categorized as "Test Sources". The same way, rules are usually targeting Main sources only.
The code base I am working with has a lot of generated code. In addition, there are also some deprecated files that I would want to exclude from SonarQube analysis. I've read up the documentation and looked at some answers on here about that, but it does not help in my case.
I have a multi-module maven project. So I have multiple projects in my workspace that are all part of a large application. Say I want to exclude this file:
/home/username/workspace/com.mst.rtra.importing.message/bin/com/mst/rtra/importing/message/idl/parse/idlparser.java
I don't really know how to write this in the exclusions settings on SonarQube because of how long the filepath is. Also, what if I want to exclude another file, but from a different module, say :
/home/username/workspace/com.mst.rtra.interpreter.create/
I am confused about I should write this in the exclusions box in project settings. Should I write the absolute file path due to the multi-module nature of this project? Or is there some other convention used?
In addition, if I want to exclude generated files from analysis, I would need to put file:/generated-sources/ as I saw in another answer. However, after analysis, I can still view the analysis results of those files when I open up the project in SonarQube dashboard.
We use ant rather than maven, and an older version of the Sonar ant task at that. But what works for us is setting a sonar.exclusions property in our build.xml, which accepts wildcards for filenames. For example:
<property name="sonar.exclusions" value="**/com/ex/wsdl/asvc/*.java,**/com/ex/wsdl/bsvc/*.java"/>
That skips analyzing all the code generated from a wsdl file for two services. You ought to be able to do something similar for maven.
My co-workers and I would like to incorporate SonarQube into our existing projects. Our normal development process for Java projects involves running Checkstyle on code changes to ensure they follow our style rules, committing the project to our code repository and having Jenkins build and package the latest version. We’d like to add SonarQube to this final step (through the Jenkins plugin) but we don’t want to duplicate all of our Checkstyle rules in SonarQube, since this would require us to maintain two separate sets of rules and make things more complicated if we need to make changes to the rules. We don’t want to completely switch to SonarQube since we’d like to still run Checkstyle before we commit code to our repository. We’d also prefer to maintain our own Checkstyle files as the main set of style rules as opposed to maintaining the style rules on SonarQube and downloading the generated XML files for our local development.
So is there any way to “upload” (so to speak) our existing set of Checkstyle XML files to SonarQube for it to use in its evaluation?
Thanks for the help.
AFAIK, it is not possible to have Sonar use the Checkstyle definitions from the repository. Is is, however, possible to have Sonar use the current Checkstyle suppression filter from the repository.
As for the rules definitions, I think you will have to maintain them in Sonar, and when anything is changed, also change the copy in the repository which is used by eclipse-cs. This is redundant, but at least it affects only one person - the rest of the team can reap the benefits. This approach also enables intentional differences, e.g. when some Eclipse-specific issue is checked (say, something concerning source folders, which don't exist in Sonar).
The path to the suppressions filter file can be configured in Sonar to refer to the location where your stuff is checked out for Sonar analysis. So that part can be maintained in the repository without any redundancy.
From my point of view, you should make a choice: use SonarQube or Checkstyle but not both.
Checkstyle on code changes to ensure they follow our style rules => Can't you replace this step with SonarQube. See for example: http://docs.codehaus.org/display/SONAR/Using+SonarQube+in+Eclipse or http://docs.codehaus.org/display/SONAR/Issues+Report+Plugin
I am importing my full binaries folder which contains binaries of classes I don't want to analyze, as well as tests that I also want to analyze. Despite Sonar documentation stating that the sonar.properties property supports comma separated values, it is incorrect. If I try to include many folders, separating with a comma, only the first folder path will be included in the analysis.
I know in the Sonar dashboard you can exclude source files, but it does not say anything about excluding .class files.
I know in the Sonar dashboard you can exclude source files, but it does not say anything about excluding .class files.
Following "SONAR - How to exclude packages that is defined under “sonar.test”", a directive like:
/path/to/class/dir/**/*.class
should exclude all .class files.
It should be fairly similr to the sonar.exclusions Analysis Parameter.