Hey there, we currently have a setup with sonarqube in our CI pipeline, with PR decoration, which also configured to block merges in case of a “red” result, which is intended in like 99% of the cases.
However, in some rare cases we whish to “ignore” findings, for example when it is about touching (or just reformating) legacy code, or when there are really good reasons for a PR that the given coverage cannot be reached (this should be rather the exception, but it can happen). Also, sometimes the coverage metrics may yield false results (for example in kotlin code with inline functions).
Currently in our setup the only way to work around those issues is to use “Admin Power” to merge those specific commits, but I would like to improve that workflow a bit and I am not sure if SonarQube does support this.
Like in issues, where you can set particular findings as “Won’t fix” (with an explanation onto why) or “False positive”, I am missing a similar feature for coverage and duplication metrics. Can you somehow, in a PR analysis, mark a uncovered code range as “Won’t fix” or similar so it will be excluded from the overall rating and not yield to a red status for the PR analysis?
Or are there any other patterns or best practices on how to deal with such a situation?
