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:
- adding two un-coverable lines to fix an issue leading to a 0% coverage on new code
- 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?”