Hi guys,
I find it unfortunate that this old topic was resurrected with such an aggressive tone. Maybe it’s not easy to find if you don’t know the right key words, but this question has been asked - and answered - several times in this community in the last few months:
- SonarQube7.2 and BitBucket Integration - #6 by NicoB
- https://community.sonarsource.com/t/pull-request-branches-to-include-code-coverage/318/17
- https://community.sonarsource.com/t/github-pull-request-review/3273/3
- Reject PR in Azure DevOps when test coverage is low (SonarCloud) - #2 by ganncamp
- Quality Gate passed even with zero coverage - #5 by Andreas-Huber (altho to be fair this one is from today)
To be explicit, each of these threads references
MMF-1369 - Real Quality Gates for PRs and short-lived branches
The goal of which is to enable you to “make [your] own decisions about what quality is acceptable to [you] for all branches, short or long term”. Feel free to watch and vote for this initiative, which is currently tentatively scheduled for 2019Q1.
In the meantime, yes there is a hard-coded gate on PRs and Short-Lived Branches. At initial implementation our choice was doing that or doing nothing. We picked the former as the lesser of two evils, especially since we don’t impose a zero leak policy, we just make sure you’re aware of what you’re doing when you add issues in the leak. As described above,
To be super explicit about this, if your PR has no Status=Open issues, then it goes green, even with non-fixed issues. And it doesn’t just go green in SonarQube; PR annotation is updated as well when the last Open issue is moved to some other status. So, to not be blocked by “a draconian zero leak policy that cannot be modified”, simply “Confirm” all your Open issues.
If you’d like a civil discussion of other pains you have around this topic, please feel free to start a new thread.
Ann