Preventing com.sonarsource.sonarqube from blocking PR when issue is just "low code coverage"

SonarQube
, ,
1

When using “com.sonarsource.sonarqube” as a bitbucket’s code insights report, we can block pull requests from being merged if its PR sonarqube analysis is failing the quality gate: this is obviously desirable to keep the number of bugs, vulnerabilities, and code smells to zero, but blocking a PR due to “coverage on new code below 80%” is often an hinderance to the development process. Here are two example scenarios where we might want to merge a PR even when coverage on new code is low:

  1. adding two un-coverable lines to fix an issue leading to a 0% coverage on new code
  2. writing an emergency hotfix for which we don’t have tests yet

Ideally, when code coverage on new code is below 80%, the quality gate should still fail to catch developers’ attention by showing a red decoration, but the com.sonarsource.sonarqube report should not block the PR because of it.

Given the above, I suppose the question is: “can we somehow customise the com.sonarsource.sonarqube report?”

2

Hi,

Welcome to the community!

I need to start by saying that in general, we see it as best practice to enforce high (80%+) coverage on new code.

That said, there is already a feature in SonarQube to not enforce coverage and duplications conditions on new code when fewer than 20 lines are changed. It is on by default and must be explicitly disabled (Administration → General) at the global level to not be kicking in for you.

Selection_1331

Whether or not this addresses your second scenario obviously depends on how large the hotfix is.

So your options are to get this re-enabled, or remove those conditions from your Quality Gate altogether, which - again - we see as a Very Bad Idea.

 
HTH,
Ann

1 Like