I have to do an audit of the Sonar issues in my project that have been suppressed with //NOSONAR.
Is there a way to do a scan that ignores the directive so that I can see which violations have been suppressed?
Most of SonarQube language plugins provide a built-in rule to track NOSONAR usage:
"NOSONAR" should not be used to switch off issues - This rule raises an issue when NOSONAR is used.
(see Java example or list of equivalent rule for other languages)
Enabling this rule in the relevant Quality Profiles will let you continuously track NOSONAR usage (and potentially take in into account in your Quality Gate).
As for getting details on the actual issues that were suppressed, no there is no way to ignore a directive that is precisely made to ignore issues.. As Bohemian suggested you're better off running an ad-hoc analysis with the NOSONAR flags removed and see which new issues get raised (avoid doing that on the existing SonarQube project to not add noise to its history).
Related
I want to modify / make the rule target only public interfaces (not public classes etc). Is this possible ? Im using this rule in Java code but its too strict for my project and I would love to know if there is a way to change it a little bit.
Link for rule: https://rules.sonarsource.com/java/RSPEC-1213
For an existing ruleset on SonarQube, talk to your sonar administrator to change the rules that are enforced on the code and remove that particular one from global enforcement.
There have been a few times I've gone to the admins of the tool for the install that I use and said "this rule isn't one that I care about or will enforce and only makes it confusing" and had them remove that rule from the globally run ruleset.
Is it possible to write your own rule?
Yes, it is possible. From SonarQube's docs: Adding coding rules you have some options. Either you can write a plugin for SonarQube and add that to your instance (docs), or you can write an external application that analyzes the code which SonarQube consumes.
If you don't have your own instance of sonarqube or aren't up to writing the associated plugin or external tooling... you might want to instead lookout PMD (site).
For PMD, writing a custom rule can be much simpler (docs). One of the ways that PMD works is by 'compiling' the Java code into an XML representation of the abstract syntax tree for Java and then running xpath queries against that XML (tutorial).
The xpath rule can then be included in a project's configuration.
What about turning it off for the code that I'm working on?
If a specific rule is one that you don't want to invoke, you could suppress it with #SuppressWarnings("java:S106") (that particular spares warnings is for System.out.println use, but the same structure can be used for other warnings) or by adding // NOSONAR too strict on the line. There are spots where I have such comments where following the rule for a particular set of code is problematic and suppress it for that line, method, or class - with the comment about why that is done.
That particular rule... I'm gonna agree with the Java (and now Oracle) guidelines and follow it. The reason is that if anyone else works on the code, they'll expect it to follow that convention. Having a consistent understanding of what things should be where in code so that another developer doesn't need to go dig through an entire file to find the constructor when it is expected to be at the top (under the field definition) is a good thing. What's more, it limits the future cases where a developer goes through to make things consistent with conventions and results in a lot of style: updating code to follow style guide commits later.
We are using Sonar Qube 6.7.3 and sonar-java-plugin 5.3
We have made below changes to our sonar configuration recently
Enabled new rules
Changed configuration to include byte code(changed from 'clean sonar:sonar' to 'clean package sonar:sonar')
We are using sonar svn plugin and provide valid credentials to it.
I understand providing byte code to sonar will help it identify more issues but, I expect Sonar to flag new issues based on svn code commit date and last analysis date, but it is not.
Please let me know why it is flagging issues in old code as new?
Sonar Sanner always scans the entire code base. If somebody has decided that some code structures are wrong or dangerous (the ruleset have been changed) then SonarQube has to notify about all occurrences of that code. Why? Let's think about the following example:
After a plugin upgrade, SonarQube provides a new very important security rule which forbids the use of a dangerous cipher algorithm. Now is the question:
is it only dangerous in new code?
is it always dangerous?
Of course, it is always dangerous. SonarQube doesn't force you to fix everything (usage of the quality gates is optional). Its main goal is to let you know how many problems (code smells/bugs/vulnerabilities) exist in the whole code base.
I need to temporary ignore rule "Insufficient branch coverage by unit tests" (common-java:InsufficientBranchCoverage).
Reading http://docs.sonarqube.org/display/SONAR/Frequently+Asked+Questions I see that SuppressWarnings should work for all rules.
But any combination of
#SuppressWarnings("common-java:InsufficientBranchCoverage")
#SuppressWarnings("InsufficientBranchCoverage")
#SuppressWarnings("java:InsufficientBranchCoverage")
does not work for me.
I use Sonar 5.0, Sonar Java plugin 3.0.
Edit:
This warning may be supressed (removed) from sonar UI. I see two solutions
disable the rule 'Insufficient branch coverage by unit tests' for my quality profile. The drawback is, that rule is disabled for whole project, not just for single class
mark issue as ignored when browsing issues drilldown. This ignores only single occurence of the issue. The drawback is, issue need to be marked in every sonar project (we have project-per-branch). When I need to remove warning, I must do this in sonar UI again, for each project.
Unfortunately, it is not possible.
The InsufficientBranchCoverage rule applies directly at File level and it is consequently not linked to any particular line in the file. To remove issues related to a given rule key using #SuppressWarnings, the rule has to apply at Class or Method level (as you can read in the documentation).
Note that to guarantee consistency of the results of the analysis, we can not disable the issue at File level, as it may end by hiding issues which would have been perfectly legit (take for instance the situation of a java file having multiple classes).
We have big-old Java project with a lot of legacy code. Now we have code conventions and Checkstyle rules to check it.
We want to configure Jenkins job, which runs after every commit to SVN, to check, if modified/added lines are not violate any our Checkstyle rule.
It's not an option to check whole project, because of legacy code. Also we can't just reformat all the code, because then it will be difficult to determine who changed a particular line and why.
The approach we consider - to make diff between previous and current Checkstyle report, and see, if there are new violations.
The question is - how we can get access to the previous Checkstyle report in Jenkins?
Or how to configure checkstyle to fail build only if there are new violations?
And may be there are ready-made solutions for such check?
This is a bit round-about, but if you set up a Sonar instance to analyze your project, you can query violations data programmatically through it's remote access API. You know the violations count in the legacy code (presumably, that number won't change frequently). That's your baseline - you don't want the count to go higher than that.
So inside your CI job, you could add a script at the end that calls Sonar to get the count of violations at each of the severity levels you care about (Blocker, Critical, etc), and fail the build if the current count exceeds the threshold/benchmark.
Sonar is pretty awesome overall, especially for projects with lots of legacy code, 'cuz you can drill down and figure out where your riskiest areas are. They've got a public instance running if you haven't checked it out yet.
The solution was to make a bash script which make diff with previous checkstyle report and fails build if there are new violations.
Have you checked on Checkstyle Plugin that is available for jenkins? It will generate reports for each commit and you could compare the results for each change. Each commit will trigger a new build and a new report will be generated at the end.
Have you checked on Checkstyle Plugin that is available for jenkins? It will generate reports for each commit and you could compare the results for each change. Each commit will trigger a new build and a new report will be generated at the end.Shiva Kumar
Of course I checked it, but the question is - how we can get access to the Checkstyle report from previous biuld?
May I also suggest the Static Code Analysis Plug-ins. This will show you the trend line of Checkstyle issues as a nice graph. You can also use this with the CI Game plugin that will award points for fixing Checkstyle issues, and deduct points for causing more checkstyle issues.
I've found the CI Game plugin to work really well -- especially if you get your developers involved in a bit of a contest:
We're adding a little something to this month's contest. As you all know, first prize is a Cadillac Eldorado. Anybody want to see second prize? (Holds up prize) Second prize is a set of steak knives. Third prize is you're fired.
Alec Baldwin as Blake in Glengarry Glen Ross
It's amazing how fast those Checkstyle issues get fixed when you turn it into a fun game.
At my company we started using CheckStyle, FindBugs, and PMD to check our code quality and unify our programming styles. These tools are very effective but unfortunately they have some overlapping rule sets.
Are there configurations available online which have removed the overlapping rules?
Of course, these default rule sets are not applicable to every project but it would be a good starting point for us. We could take this default (non overlapping) configuration and adapt it to our style instead of pruning the rule sets for duplicates first.
Sonar ships with some pretty good configurations called Sonar Way and Sonar Way with FindBugs which don't appear to have any overlap between the different tools (CheckStyle, FindBugs, and PMD). They seem to fulfill my needs as a decent starting point for a configuration without all the superfluous rules.
PS I was hesitant to answer my own question but nobody else had an answer or even an insightful comment. This thread on Meta also seems to think it's okay.