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.
Related
I've started working with jHipster on a recent project which is a tool you can use to autogenerate the full stack of a REST api application using a Spring Boot back end. Which should save a great deal of time writing boilerplate code...
Unfortunately, at my work we have coding standards to adhere to in the form of a set of CheckStyle rules. Any code that does not adhere to these rules causes the build to fail. What I am experiencing at the moment is that this autogenerated code is failing the CheckStyle rules in a large number of places. Currently I am handling this by manually trawling through the code fixing each of the issues.
I can't help feeling in the back of my mind there must be a better way of doing this e.g.:
Configuring the IDE (intelliJ) to ensure the generated code matches the CheckStyle rules. This is certainly possible when coding directly into the IDE.
Configuring jHipster to be aware of the CheckStyle rules before autogenerating the code.
Running a script afterwards which can automatically fix any CheckStyle failures. (I'm sure this must be doable!)
It would be good to hear if anyone knows what the best way to address this issue might be and if anyone has done something similar in the past.
Suppress violations on all auto-generated files as it is out of your control.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter
If you have auto-generated code inside a file with non-generated code that you maintain manually, use comment suppressions.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionCommentFilter
You shouldn't be styling code you don't write for this exact purpose, you aren't writing it and some utility is and it wasn't built to your style specifications. If you generate the files again, it will undo any manual changes you made.
I'm creating some rules to SonarQube where it will analyze a Android Project and raise some Security vulnerabilityes points on code.
I've already created a custom rule by Sonar Tutorial to create my own rules following the same structure, but I had some complications. For instance, when I tryed to run the test classes, I've found some problems to identify Android Classes and validate my rule, and after some research, I solved the problem, but seems like when I put my plugin on SonarQube and run it, the problem remains with the tool not identifying Android Classes (I coudn't comprove this because coudn't find a way to debug the web tool and see why the Rule is not checking).
By this, I need to know if I'm really doing this of the right way. Analyze with custom rules a Android Project directly by SonarQube can be done just following the Sonar Tutorial? Do I need of custom configurations inside my template or any other step to do it?
If beyond the answer or the instruction, someone could provide some documentation to help me, I would be deeply grateful.
Since now, thanks for your attention!
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).
I am working on a project aims to make software reuse easier. The final project provides a framework to select a desired feature from a (Java, C++) program and adds that to the another program.
I am responsible for two parts of the project.
Fixing possible compiler errors after the desired feature is added to the another program.
Changing the desired feature to be usable in its new location. In this case the program should pass successfully all test cases (not details at the moment as my question is related to Section 1).
Currently, I implemented the first step and the program can automatically fix possible compiler errors after the desired feature is added to its new location. It almost supports all Java compiler errors (even that some of them never happen in the above project), and in few of cases a user needs to help the plugin to fix the compiler error.
Note that the plugin has access to both programs and using these information it will fix compiler errors.
For clarity, as a very simple example in a case that there is a dependency between the desired feature with a library in its original location, the plugin tries to fix the compiler error for example by adding that library to the program.
I know current IDEs provide suggestions in a case that there is a compiler error in the program, but the advantage of the current plugin is that it automatically can fix compiler errors, and does not provide a list of solutions to the user for each compiler error.
The question That I am facing is that: Any one could please mention other situations that I can use the implemented automated compiler error fixing plugin? (of course except the above project). Any suggestion is welcome as it helps me to see other directions of the project.
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.