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.
Related
I'm kinda new to SonarQube and I just found this:
Question: How? Shouldn't the Quality Gate be failing? Or do the quality gate only work for new code?
The quality rules are the default ones
Yes, it is possible. Why? It depends how the Quality Gate is configured.
Copied from SonarQube Quality Gates documentation:
Each Quality Gate condition is a combination of:
measure
comparison operator
error value
For instance, a condition might be:
measure: Blocker issue
comparison operator: >
error value: 0
Which can be stated as: No blocker issues.
Your Quality Gate could be configured to check only new code or even to not check the code at all.
Sonar way (Built-in) Quality Profile on SonarQube 7.9.2 checks only new code:
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?
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.
Is there a way to overwrite the quality gate status of a Sonarqube (5.6) project?
Use case is that we check for technical dept on new code to not be higher than 5%. In case there are additional rules activated in the quality profile, next time a project was checked it will violate the quality gate, even though the technical dept was not introduced by new code but with new rules instead.
Currently there is no way to overwrite quality gate status. From this thread on Google Groups by G. Ann Campbell:
There's not. The best approach is a strategy one: only update the profile / add rules when a new version is just beginning.
Of course, that doesn't really address the issue that new rules raise "new" issues on old code. For that I don't have an answer.
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.