Hi there,
we set up gates with 100% coverage on new and all code. Why does the gate pass, when it says “99.7% coverage after merge”? Did we miss something in our account setup?
Thanks in advance for having a look into this 
1 Like
Hey there.
In a pull request, only conditions on New Code are evaluated. And as there appear to be no new lines that can be covered by code (what we call “executable lines”), the coverage condition won’t trigger.
(There is another specificity: Conditions on Coverage on New Code and Duplications on New Code aren’t applied when there are fewer than 20 lines of new code.)
Hi Colin thanks for reaching out! Is there a setting to change that? So we enable that also conditions are checked against all code on PRs?
Hey there.
It’s not possible. We expect developers to only be responsible for changes in a pull request, not on past code merged.
Let’s take the example you’ve given: 100% Coverage on Overall Code. Putting aside whether that’s a reasonable (or even desirable expectation), it means that the Quality Gate on your PR would fail on the .3% of code already in your main branch that isn’t covered. Should the developer responsible for this PR really be responsible for that .3%?
Hi Colin, that’s why we opened this thread in the first place: The production branch has 100% coverage and the changes in this PR are responsible for the drop, but somehow not caught.
Sorry I didn’t share that part initially.
Gotcha.
This is a case that SonarQube doesn’t cover. You may be interested in joining this discussion on “ratcheting” Quality Gates:
Thanks Colin, I also upvoted for the card on Productboard. Just for clarification because you said SonarQube: This would also apply to SonarCloud, right? We use the latter.
It’s complicated – but ideally, yes, these features apply solution-wide (Sonar____)