We Keep Coding

Sonar rule for interfaces only RSPEC-1213

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.

Sonar is showing new violations in old code

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.

Change SonarQube's Quality Profile Based on File Name

It's really easy to have use cases where a SonarQube rule can be important for some files, but completely useless for others, I'll just give some examples:
The rule "Missing translations should be added" is really great for finding missing keys in all kinds of messages_xx.properties. However each group of properties files always has an empty messages_en.properties (at least for us, where English is the default locale). For this files it's an actual bug to add keys to.
Another example is "String literals should not be duplicated": in normal Java files duplicated strings introduce bugs (because you might change one and not the other). In test files enforcing this code leads to unreadable code, because the duplicate code usually is in the initialization of the tested objects and / or the messages printed out when the test fails.
I could easily go on with how test cases differ from "real" Java classes. Even though test code should have the same quality measurements, in practice it's quite different.
The question is now: How to handle these rules in Sonar?
The trivial answers I already discarded:
remove the rules entirely (they are quite useful)
fix the rules (the first example even introduces bugs into the code)
mark the test as won't fix (it's just too much)
So I guess I want to change the Quality Profile based on the project (e.g. exclude org.acme.project.it) or a file name (e.g. exclude *Test.java). Or maybe enable rules only for some file name patterns.
What is the best way to handle SonarQube rules that only work on a specific group of files?

You want to set up some exclusions. Exclusions allow you to ignore certain files completely, or to conversely ignore all but the specified set of files. You can set up exclusions for coverage or duplications. And most pertinently to your question, you can set up multiple flavors of issue exclusions.

How to ignore //NOSONAR during scan?

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).

Checkstyle and Jenkins: check modified/added lines in SVN commit

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.