Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) Sonarqube 9.9 , community license
- how is SonarQube deployed: zip, Docker, Helm NA
- what are you trying to achieve:
- what have you tried so far to achieve this
ignore duplication and coverage on small changes should apply to uncovered lines not to total lines. Its quite confusing use the total lines for something that is not taking into account that lines (white spaces, curly-braces, comments).
I have an example with 25 lines in total, just 3 lines to cover, and it fails because of the change is not small enough.
Due to duplications and coverage use the number of uncovered lines, this number should be whatever you consider but for uncovered lines, not total new lines.
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
I’m a bit confused. Are you saying that when duplication and coverage Quality Gate conditions are ignored on small changes the
lines metric shouldn’t be used for the test? We agree, but have never gotten around to fixing it
SONAR-11283 Quality Gate should not fail when too few lines to cover
Unfortunately, I can’t find a parallel ticket for duplications.
Is there any news on this topic?
We are using SonarQube 10.3 and this is starting to be a problem for us.
The developers fix a little bug which leads to very few lines to cover and they write tests for this. The resulting new lines of code are well above the default threshold of 20 new lines of code.
We even had a case where there were 60 new lines of code but only 1 new line to cover and the quality gate failed.
It means we are punished for writing tests because then the new lines of code are higher than the ignore threshold - this leads to developers writing less or no tests when fixing bugs to avoid this behaviour which is absurd.
At this stage, there are no plans regarding this development as we did not get enough feedback from users.
What kind of feedback do you need?
You already have this issue since 2018 with highest priority in your issue tracker so normally people would think they don’t have to report it themselves again so naturally there won’t be many users writing here about this problem.
What do you suggest we do to make sonarqube usable for us even when we just make small changes which is quite normal for bug fixes?