I want to merge the reports generated by PMD, FindBugs, and SonarLint to give the user a more general preview by combining the important warnings reported by each of them. So can someone suggest to me as how can these individual reports can be merged?
We use warmings-ng plugin for Jenkins, it can aggregate multiple reports from different static analyzers.
It can be used in Jenkins pipeline like this (it aggregates warnings from maven build output, java compiler and checkstyle)
recordIssues aggregatingResults: true, tools: [checkStyle(), mavenConsole(), java()]
Full list of supported tools you can check here (all analyzers you mentioned are supported)
Related
It has been cleared here that from Sonarqube version 6.2 that coverage reports are merged and there won't be separate unit and integration coverage report anymore.
We still interested to have these two coverage reports separately. So, We have three sonar projects: unit-tests, integration-tests, whole-project(which is responsible to create overall coverage report)
Problem: All source files are analysed in all three projects. Since the number of files are too many, it takes several minutes to perform the analysis.
Question: Is it possible to turn off sonar issue analyser somehow in a project? It is desired to report only test coverage in the the first two projects(unit-tests & integration-tests) without analysing all files, and then run the issue analyzer only on the last project(whole-project). It could help us to analyse all files once instead of three times.
Additional info: We use sonar gradle plugin version 2.6.2 and sonarqube version 7.4
SonarQube/SonarCloud main responsibility is informing users about issues. Displaying code coverage is just an additional feature. It means there is no flag/parameter which allows you to do it.
Luckily, there is a workaround. You can create empty quality profiles, and use them to scan those two projects (unit-tests & integration-tests). You will get 0 issues because there are zero rules enabled.
The following feature request should be interesting for you: Making test coverage measures mode useful. Feel free to vote on it.
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 testing SonarQube with a .Net solution file. I'm trying to figure out which files exactly get uploaded/imported into the SonarQube database. Based on my tests with the SonarQube MSBuild runner, it analysis and uploads all files which are stated in the .csproj project file(s) (only those that can be associated with a language plugin because I have set "Import unknown files" to false).
Is there a way to specify additional files which should be analyzed and imported? I had some hope for the "sonar.inclusions" setting, but it's not exactly what I need because the description says Patterns used to include some source files and only these ones in analysis.
I'd like to just specify additional files.
My use-case: at the moment, SonarQube does not create issues for compiler warnings (see Displaying C# compilation warnings in Sonar?) (which in my opinion is really sad/weird for a tool that wants to improve code quality). So my idea is to use msbuild with an xml-logger, import the generated xml log file and use the XML plugin with custom XML path rules to extract the compiler messages.
Similar issue for analyzing Delphi code. I found an old SonarQube Delphi plugin which I could not yet get to work with SonarQube 5.x, but I'd like to try to get at least the compiler messages into SonarQube (convert Delphi compiler output into XML, get SonarQube to import this file, use custom XML path rules).
Is there a way to get SonarQube to analyze/import such additional files?
Does Sonar offer any way to raise alerts and fail a build when the trend for certain metrics is bad?
Background: In our legacy project using a static threshold for example for code coverage ("red alert when coverage is below 80%") does not make much sense. But we would like to make sure that the coverage does not go down any further.
Please do not give any advice on lowering the bar by using a less restrictive rule set. This is no option in our case.
There is a build breaker plug-in that will fail the build if you breach a Warning or Error threshold setup in the quality profile.
Plug-in details are here:
http://docs.sonarqube.org/display/PLUG/Build+Breaker+Plugin
Not aware of any functionality that enables you to a metric trend.
We use Sonar as the second last step in our release process. The build breaker ensures that releases do not breach predetermined quality criteria.
We tried exactly the same, using the build breaker plugin. After a while, it showed to be too unflexible (and configuring Sonar is a mess), so we moved from sonar to Jenkins/Hudson plugins like Cobertura (for code coverage) or PMD for code style:
https://wiki.jenkins-ci.org/display/JENKINS/PMD+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
With these plugins, very fine-granular settings are possible, to set for example the build to yellow at <70% code coverage or to red by <50%; even the weather-symbol for each build is setable.
In the meanwhile we scripted our own buildbreaker that gets excecuted within our build. We use Groovy to query the REST API of Sonar to retrieve a certain set of metrics (including their historical values). The retrieval of metrics is provided by a build plugin that is provided for our whole division.
Each team can parameterize their build with a set of rules regarding those metrics that have to be verified for their project. Of course, the rules are also provides as Groovy snippets :-)
Typical are:
Number of (major|critical|blocker) violations is less or equal than in previous build
No new duplicates
Coverage not lower than in previous build
Bad findings can then be used for breaking the build or just for reporting.
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.