Ignoring issues on a PR check

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using 7.9
  • what are you trying to achieve
    SonarQube reported an issue on a PR and now the check on GitHub is failing. I want to ignore the issue so the check will be green - but I’m not sure how to achieve that.
  • what have you tried so far to achieve this
    Google “how to ignore issues”
2

Hello Omer,

First of all, why would you want to ignore issues ?

  • If the issue is legitimate why would you want to ignore it. You should fix it. If you want to fix after the merge (not recommend) you just have to live with Failed PR check and merge anyway.
  • If the issue is not legitimate (eg a false positive), you can mark the issues as False Positive or Won’t Fix in SonarQube which will have the effect of ignoring them in the PR, and your PR check will pass

See: https://docs.sonarqube.org/latest/user-guide/issues/

Regards, Olivier

3

I might be missing something - but I don’t see an option to mark the issue as false positive:

image
image.png1712×208 27.4 KB

Where is this option?

4

Hello Omer,

You don’t have the option because you don’t have enough permissions on the project. You need Issue Administration permission.
See Project Permissions paragraph at https://docs.sonarqube.org/latest/instance-administration/security/ to understand permissions.

When you have Issue Administration permission on a project, you have pull down menus on issue Type (Code Smell, Bug, Severity), issue Severity (Blocker, Critical, Major, Minor, Info) and Issue status (Open, Confirmed, False Positive, Won’t Fix, Fixed) to perform manual changes, eg mark as False positive or Won’t Fix. The below screenshot shows the pulled down issue status menu

image
image.png1786×497 101 KB

:warning:This Issue Administration permission should be used wisely and scarcely. If you abuse it by using it to artificially lower the importance of issues or even completely ignore them (eg “Won’t fix”) on a large scale, then you completely defeat the purpose of your code quality and security tool :slight_smile:
In production, this is a permission probably only to be granted to senior developers/tech leads that should be the only one to perform those changes after some good thoughts.

Regards, Olivier