Currently our PR’s will be blocked if the code coverage is below 80%.
Just as with issues, we can mark them as “won’t fix”, or “false positive”, is there a way to do this with code coverage reporting from sonarqube.
Hi,
There’s not a way to do this. Could you explain a little more about your use case? Why can’t you simply ignore the failing QG and merge anyway?
Ann
I guess the context is that we are considering blocking merging till all the sonarqube issues are resolved. e.g. with code smells you could mark them as won’t fix, or false positive, and this can stop the quality profile from failing, but not so with code coverage
Okay, thanks for the explanation. I’m going to move this to the New features category.
Ann
Hi Ann,
we are also interested in this feature. Any news on the current status?
Thanks and BR,
Michael
Hi @mher,
This is a topic we are thinking about for the future.
Would you mind sharing more about your use case? Do you have specific reasons to occasionally bypass the level of coverage that you expect from your PR?
Chris
Any update on this. It would be a nice feature to have.
Main use cases I have come across where this would be helpful are when making large changes, such as reformatting an entire codebase (using a tool like prettier). If the existing codebase is not meeting the coverage threshold, then the QG will fail and merge checks will block the PR. In this case it wouldn’t be in the scope of the PR to also fix all the coverage issues.
At the moment the workaround is to simply remove the merge check, merge the PR and then re-add the check, which works, but would nice to just have an option in sonarQube to say “I’ll fix this later” to get the QG to go green.
Hello Richard,
Thanks for sharing this feedback. We are monitoring this requirement. I do not yet have a timeline that I can share at the moment.
I’d like to echo the request here. It is a bit painful process wise to request our repo admins disable the merge/branch protection requirements just to bypass the quality gate for a single PR. Some feature to allow for the bypass of a QG requirement being met is a much better grain to apply a bypass on rather than the entire suite of checks done as part of our CI process.
Hi all,
We are aware of this pain point.
If you care about this, please add your voice here.
For now, it is not obvious how we could solve it without introducing some significant changes to how coverage works in our products. So, feel free to continue sharing in this thread.
For example, if you can share more details and specifics. In what cases does this happen? How problematic is this to you? What workarounds have you found? Etc.
More so, don’t hesitate to share potential solutions or ideas that could work for your case.
This all helps.
This is exactly our use case as well.
The work around we use at the moment is to skip sonar for some merge requests completely (remove the step from the CI pipeline per MR).
We have this use-case too. Having to twiddle knobs in Github to get the exception through is a right nuisance. I there was a button to accept or false-positive the coverage or duplication issue on new code, that would improve our workflow.