This is apparently due to some PR’s not getting evaluated for Code Coverage due to a low line count.
If you want to apply the line count minimum exclusion for the new code in the PR, then its only fair to do the same for all new code and apply the same exclusion for the main branch new code. If that seems like a lot of work and potential calculation problems, then just get rid of the 20 line exclusion for PR’s. The current inconsistently applied calculation sets teams up for a late failure and to have to dig out of a hole rather than clean as you code.
The reason given was that a developer making a hotfix should be getting an exclusion. This line of thinking is incorrect and intrusive in most cases. A hotfix is needed due to a bug. If there were tests already for this code and they didnt catch the bug, they were wrong and need to be changed also. But if an org sets a quality gate, they are expecting it to be followed or are OK with some things not meeting the quality gate. Its up to them.
If the developer needs an exclusion and are permitted to do so by their team or organization, they can always add the corresponding exclusion, be it in the code using whatever language facility is available for this, or via the sonar properties. It is not SonarSource’s decision to make yet its being forced on customers…
Sometimes a new feature or non-hotfix bug fix only takes a single new line. These are also excluded from the quality gate now, only to be reported as a problem later. This later is often when someone from management looks over the sonar stats and sees new code coverage percentage looking awful and wonders what kind of games developers are playing to make the PR’s pass.
Those are all problems we dont need that this 20 line exclusion creates.
)