Hello Sonar team,
I would like to define different quality gate on a single project because I did not have the same requirement between my PR and my main branch.
For example, I would like that all my PR reach 90% of code coverage on new code and at the same time, I would ensure that code coverage on my main branch reach 60% on new code (with new code definition configured at “previous version”)
It would be valuable for my teams starting to use SonarQube on legacy projects.
Could you explain the need a little more?
Assuming all your PRs reach 90% coverage before they’re merged, wouldn’t your main branch naturally have 90% coverage on New Code?
Or is this about PRs with <20 lines not triggering the checks on coverage & duplications? You know you can toggle that off now, right?
You’re right, on coverage the impact will be limited unless developers bypass quality gate status and merge anyway.
I can see more discrepancies on duplication (I could introduce only 1% on my PR but it could result in more than 3% in the target branch) and number of code smell.
So you want more stringent requirements on PRs so that they won’t - cumulatively - break the main branch QG after merge?
Based on your example, you’re concerned about multiple PRs, each with <3% duplications cumulatively failing the project QG after merge?
And to generalize, this would apply to any numeric condition (so not the ratings) where the operator is “is less than”.
Have I interpreted that correctly?
Yes, Ann that’s exactly the idea