Sonar scanner runs analysis for all the available plugins installed in SonarQube. But for some of the projects analysis should be run only for some languages(For example Java and Javascript).
sonar.language parameter allows me to set only one language.
Is there any way to set multiple languages for analysis.
Stop thinking in term of language, since this is a blur concept in SonarQube. Just exclude the files you don't want to analyze, using for example the property sonar.exclusions.
For example, when considering a pom.xml file, the "language" was historically XML (and rules provided by SonarXML). But we now also have rules provided by SonarJava.
The property sonar.language was deprecated in SonarQube 4.4 and might be removed in SonarQube 6.7 or later, because SonarQube can now use several languages (which seems to be exactly the issue that you face currently).
If you only want Java and Javascript issues to be reported, I suggest to create custom quality profiles for all other languages, containing 0 rules. You can then, for your project, explicitly assign those "void" quality profiles.
I'm working with SonarQube 6.4 and a java project based on maven. We are using SonarQube a lot and I now want to define a metric regarding tests.
Is there a way to know how many lines of code a team has written in the test package?
This is a metric that was considered but was never considered as interesting enough (in regards to other features) to be implemented on the SonarJava plugin. See this ticket for more details : https://jira.sonarsource.com/browse/SONARJAVA-79
Since we updated to SonarQube 6.2 it seems code coverage plugin got merged in the core.
It shows red flags everywhere and I can’t find how to turn it off, we do not use code coverage.
You don't specify what language(s) you're analyzing. I'll assume Java and/or JavaScript. Starting from 6.2, SonarQube supports "force coverage to 0", which marks as uncovered executable lines in files that don't show up in any coverage reports. (That's assuming the underlying code analyzers support the feature, and Java and JavaScript already do.) The purpose is to have a more accurate picture of what's missing when you actually are using unit tests. Without this feature, it's impossible to tell whether a file that's omitted from coverage reports is missing because it has no executable code or because there are no tests on it - even when there should be.
Since you're not using unit tests (really?) you can exclude all the source files in your project from coverage calculations via the UI: Administration > Analysis Scope > Coverage Exclusions. A pattern value of **/*.* ought to do it for you.
Code coverage feature is in SonarQube misleading. To turn this off:
Under Quality gates create new or copy existing profile.
There delete Coverage metric
SonarQube Version: 9.2
I am trying to have SonarQube (6.0) with generic test coverage plugin (1.2) read the coverage report which I created for go language. Coverage report is exactly in the xsd schema that sonar expects. However the analysis with sonar-scanner 2.8 fails with following exception.
java.lang.IllegalStateException: Line 2 of report test-results.xml refers to a file with an unknown language: queue/queue.go
I am passing following in sonar-project.proeprties.
sonar.import_unknown_files=true
sonar.genericcoverage.reportPaths=test-results.xml
Can you provide some suggestion on how to go about it.
The basis of any analysis is the code analyzer which declares the language (Go, in this case). Typically analyzers also parse the language, provide metrics for it and offer some rules.
You cannot pull in coverage results for a language unless you first have this piece in place. So it sounds like you're missing a code analyzer for Go.
As G. Ann said, you need to make sure you have the Language Parser Plugin installed.
SonarQube 7.x comes with SonarGo or you can use the information in my repo for more detailed info: https://github.com/Talderon/k8s-sonarqube-golang
We are working on a web project from scratch and are looking at the following static code analysis tools.
Conventions (Checkstyle)
Bad practices (PMD)
Potential bugs (FindBugs)
The project is built on Maven. Instead of using multiple tools for the purpose, I was looking at a single flexible solution and came across SonarQube.
Is it true that we can achieve the results from Checkstyle, PMD and Findbugs with SonarQube?
Sonar will run CheckStyle, FindBugs and PMD, as well as a few other "plugins" such as Cobertura (code coverage) by default for Java projects. The main added value, however, is that it stores the history in a database. You can then see the trend. Are you improving the code base or are you doing the opposite? Only a tool with memory can tell you that.
You should run Sonar in your CI system so that even things that take some time to execute (such as CPD – copy paste detector) can run. And you'll have your history. Whereas with an Eclipse plugin, for example, you'll detect violations sooner – which is great – but you will be tempted to run it less often if it starts taking too long, or run less "quality plugins" (such as skipping CPD or skipping code coverage analysis). And you won't have history.
Also, Sonar generates visual reports, "Dashboard" style. Which makes it very easy to grasp. With Sonar in Jenkins, you'll be able to show developers and your management the effects of the work that was performed on the quality of the code base over the last few weeks and months.
Sonar uses these 3 tools as plugins and aggregates the data from all three giving addition value by showing graphs and such from these tools. So they are complementary to sonar.
Yes and no. In addition to the other answers.
SonarQube is currently on the way to deprecate PMD, Checkstyle and Findbugs and use their own technology to analyze Java code (called SonarJava). They do it, because they don't want to spend their time fixing, upgrading (or waiting on it) those libraries (e.g. for Java 8), which for example uses outdated libraries.
They also got a new set of plugins for your personal IDE called SonarLint.
Sonar is great, but if you want to use the mentioned tools separately and still have nice graphs, you can use the Analysis Collector Plugin as part of your Jenkins CI build. A slight advantage of this is that you can check in your PMD/Findbugs/Checkstyle configuration into your SCM and have it integrated into your Maven build, rather than relying on a separate Sonar server.
... a few years later: no, it is not! SonarQube supposes to be able to cover all the rules with its own analyzer, but there are still rules from PMD or CheckStyle not covered by SonarQube. See for example: PMD ReturnFromFinallyBlock.
Sonar is much more than these tools alone.
The greatest benefits is the gui, which lets you configure anything easily.
The statistics it offers are very detailed (lines of code etc).
And it even offers great support for test coverage etc :)
Here you can take a good look:
http://nemo.sonarsource.org/
I would still use these tools in addition to sonar because they can fail the maven build when someone violates a rule. Where as sonar is more retrospective.
Well at least since SonarQube 6.3+ it seems to be that Findbugs is (at the moment) no longer supported as a plugin. Sonarsource is working on replacements of Findbugs-rules with its own Java-plugin.
They even had a list for the replacement status of each rule here, but it got removed by now.
See https://community.sonarsource.com/t/where-is-dist-sonarsource-com-content/5353 for more details.