SonarQube Version: 6.7
Language: C#
SCM Sensor: Enabled
I've tried searching around but I haven't gotten any solid answers.
I am attempting to set up a quality gate for duplicate code. While testing I was able to increase my duplicated blocks count for my solution but the "Duplications on New Code" didn't increase so it didn't fail the quality gate. Setting up a static number for the duplicate code count to fall under isn't going to work since there are multiple solutions that are using the same quality gate.
When running the following Sonar command on our build system I am seeing some odd behavior:
SonarQube.Scanner.MSBuild.exe begin /k:"SonarKey" /n:"SonarName" /v:"BuildNumber" /d:sonar.verbose=false /d:sonar.cs.vscoveragexml.reportsPaths=**/*.coveragexml
Build Solution
SonarQube.Scanner.MSBuild.exe end
I have configured the Leak period to "previous_version", which based on my understanding means that any code added to the project will be considered new code.
Any ideas as to why the duplication's on new code aren't increasing?
Related
i am a Beginner with SonarQube and really tried to google and read a lot of community pages to understand which functions SonarQube offers.
What i dont get is: What does the test coverage in SonarQube refer to?
If it says for example that the coverage on New Code is 30% what does new code mean?
And when does SonarQube say that a issue is a bug? Is the analyzed code compared to a certain standard in order for SonarQube to say that there is a bug?
I hope someone with more knowledge about SonarQube can help me understand it. Thank you very much
Test coverage (also known as code coverage) corresponds to the proportion of the application code (i.e., code without test and sample code) that is executed by test cases out of all application code of the code base.
SonarQube does not compute code coverage itself. Instead coverage is computed and uploaded by external code coverage tools (e.g., cobertura, JaCoCo). SonarQube presents code coverage at different levels (e.g., line coverage, condition coverage); see https://docs.sonarqube.org/latest/user-guide/metric-definitions/#header-9.
Coverage on new code refers to the proportion of code that is both covered and added (or modified) since a certain baseline out of all added and changed code since the same baseline. The baseline can, for example, be the previously analyzed code state or the code state of the previous commit. That is, this metric expresses how extensively changes have been tested. Note that 100% coverage does not mean that code has been perfectly tested; it just says that all code has been executed by test cases.
Issues in SonarQube do not necessarily represent bugs. Usually most issues are actually not bugs but are problems affecting code maintainability in the long term (e.g., code duplications) or violations of best practices. Still, some issues can represent bugs (e.g., potential null-dereferences, incorrect concurrency handling).
Note that an issue can also be false a positive and therefore not be a problem at all.
Most issues are identified with static code analysis by searching the code structure for certain patterns. Some can be uncovered by simple code searches (e.g., violation of naming conventions). Other analyses / issue classes may additionally need data-flow analyses (null-dereferences) or require byte-code information.
I am planing to integrate my project with SonarQube. My project code base is there for many years. After the very first integration I want to skip all the issues and code coverage. I only want the new code to follow the rules and report issues. Otherwise I want my project to get pass the gates with out considering the old code.
Simply use the new ... issues conditions in your Quality Gate, i.e.
Metric Operator Error
New Blocker Issues is greater than 0
New Critical Issues is greater than 0
New Major Issues is greater than 0
This way, the Quality Gate of the first scan will always be green.
I recently used sonarqube api to create a dynamic quality gate, it increases or decreases the acceptable number for the project, according to the number of lines of code, but I'm having some problems ...
It works like this, after the analysis I use the number of lines and calculate the quality gate to increase or lower the acceptable limit
I use the sonar line count itself to avoid mismatching information, but whenever I update a quality gate, the project status is not updated.
For example, if a project was with the quality gate with the status "Passed", after I update the quality gate, it should change the status to "Failed", but it remains "Passed" because I did not perform a new analysis.
How can I request pro sonar to re-execute the project status according to the quality gate change?
I'm using sonarqube 6.0
Thanks
You have no choice but to re-run an analysis if you want your quality gate to be updated.
Just as a side note: it looks like you are trying to hack SonarQube features, I would not recommend to go into that way because you will for sure face problems. Instead, I highly encourage you to read "Water Leak Changes the Game for Technical Debt Management" and consider using the built-in quality gate that puts the focus on new code: this is the best and easiest way to improve code quality over-time with almost no effort and no friction.
Number of critical issues are 4 on my project. I have configured a condition 'Critical Issues' with 2 measure in the following order.
1. 'delta since previous analysis' 'is greater than' 0
2. 'Value' 'is greater than' 6
Please find screenshot
I had forcefully introduced a critical error and run sonar. I thought it should fail because of above 1st condition but to my surprise it got passed.
After doing multiple permutations and combinations I got to know that a unique 'Condition' should only be configured once. If a unique 'Condition' is used more than once then one which is configured later is used by Sonar and the one which is configured earlier is ignored.
According to Sonar documentation - http://www.sonarqube.org/quality-gates-shall-your-projects-pass/
'Quality Gates can be thought of in two different ways. At the practical level, they’re collections of what were once called alerts, and are now known simply as “conditions”. At the abstract level, they’re logic gates, AND-ing together all the conditions in the set to determine whether or not your project can pass.'
I could not find any information on internet to prove my findings and even sonar documentation contradicts it. Has anyone faced this issue before? Could someone confirm that a 'Condition' for example 'Critical Issues' should only be configured once.
Multiple conditions on metric(s) are definitely supported for configuring Quality Gates in SonarQube, and the documentation is in line with that.
The behaviour you are observing is most likely due to a bug present in SonarQube 5.2, 5.3, 5.4 , preventing analysis to succeed if there are multiple Quality Gate conditions on same metric, see SONAR-7276 for more details.
Now that the Cutoff date plugin for Sonar is deprecated (I've tried it, and it doesn't seem to work at all), is there any way to exclude issues based on a set date?
For a large project, it is desirable to really start at fresh at given point.
Maintaining a low alert threshold ( < 100 alerts ) is much more manageable for the developers than cluttering the issues listings with old history/low priority issues. (1500++). Identifying the new and relevant ones are then much harder.
What we want to focus on are new issues.
Example:
when you have changed the quality rules for say 200.000+ lines of code, you really only are interested in what is produced from now on and changes to already existing code that breaks the new rules.
If my feeling is correct, you're not aware of the way to work with differential periods in SonarQube. Because out-of-the-box SonarQube is designed to cover such common use case. See :
http://www.sonarqube.org/differentials-four-ways-to-see-whats-changed/
http://www.sonarqube.org/using-differentials-to-move-the-team-in-the-right-direction/
http://www.sonarqube.org/differentials-but-wait-theres-more/