Details
Description
There are some cases when there's hardly something that can be done to not have a red QG that is due to:
- missing coverage on new code
- duplications on new code
For instance:
- I want to release a simple bug fix version that implies a couple of lines - some of them being impossible (or too costly) to test.
- => impossible to release!
- Or more generally, I start a new sprint (on a new version), and the first few lines of code that are pushed are involved in a duplication
- => quality gate will be red until more lines are added: this is noise!
To fix those bad side effects, we should have a minimum number of lines under which the following conditions will be ignored when computing the QG (we ignore both "warn" and "error" thresholds):
- All coverage-related metrics on new code
new_coverage new_line_coverage new_branch_coverage - All duplication-related metrics on new code (expect file duplication)
new_duplicated_lines_density new_duplicated_lines new_duplicated_blocks
The threshold to trigger this new behaviour will be 20 lines:
- 0 - 19 lines on the leak = small change (new behaviour applies)
- 20 - x lines on the leak = big change (behaviour unchanged)
To make the user aware that something special happened, we should display a message next to the quality gate status:
Some Quality Gate conditions on New Code were ignored because of the small number of New Lines
Hovering over the little "?" should display the longer explanation:
At the start of a leak period, if very few lines have been added or modified, it might be difficult to reach the desired level of code coverage or duplications. To prevent Quality Gate failure when there's little that can be done about it, Quality Gate conditions about duplications in new code and coverage on new code are ignored until the number of new lines is at least 20.
Attachments
Issue Links
- is related to
-
SONAR-11283 Quality Gate should not fail when too few lines to cover
-
- Open
-