如何配置 Sonar 排除跳过某个检查

1. 概述

During our builds, we can use various tools to report on the quality of our source code. One such tool is SonarQube, which performs static code analysis.

Sometimes we may disagree with the results returned. We may, therefore, wish to exclude some code that has been incorrectly flagged by SonarQube.

In this short tutorial, we’ll look at how to disable Sonar checks. While it’s possible to change the ruleset on the SonarQube’s server, we’ll focus only on how to control individual checks within the source code and configuration of our project.

2. 违反示例

我们来看一个违反Java编程规范的示例:

public void printStringToConsoleWithDate(String str) {
    System.out.println(LocalDateTime.now().toString() + " " + str);
}

SonarQube 报告这段代码为 Code Smell (代码异味)，违反规范ID java:S106:

However, let’s imagine that for this particular class, we’ve decided that logging with System.out is valid. Maybe this is a lightweight utility that will run in a container and does not need a whole logging library just to log to stdout.

We should note that it’s also possible to mark a violation as a false-positive within the SonarQube user interface. However, if the code is analyzed on multiple servers, or if the line moves to another class after refactoring, then the violation will re-appear.

Sometimes we want to make our exclusions within the source code repository so that they persist.

So, let’s see how we can exclude this code from the SonarQube report by configuring the project.

3. 方法一，使用 //NOSONAR

对于单行代码，我们可以在行尾添加 //NOSONAR 注释:

System.out.println(
  LocalDateTime.now()
    .toString() + " " + str); //NOSONAR lightweight logging

The //NOSONAR tag at the end of the line suppresses all issues that might be raised on it. This approach works for most languages supported by SonarQube.

We’re also allowed to put some additional comments after NOSONAR explaining why we have disabled the check.

Let’s move forward and take a look at a Java-specific way to disable checks.

4. 方法二、使用 @SuppressWarnings 注解

4.1. Annotating the Code

对于Java，我们可以通过Java 中的 @SuppressWarnings 注解排除 Sonar 检测.

We can annotate the function:

@SuppressWarnings("java:S106")
public void printStringToConsoleWithDate(String str) {
    System.out.println(LocalDateTime.now().toString() + " " + str);
}

这与抑制编译器警告的方式完全相同。我们所需要做的就是指定规则ID，本例为 java:S106。

4.2. 如何获取规则ID

We can get the rule identifier using the SonarQube user interface. When we’re looking at the violation, we can click Why is this an issue?:

It shows us the definition. From this we can find the rule identifier in the top right corner:

5. sonar-project.properties 配置文件

我们也可以 在sonar-project.properties文件中定义排除规则。

在resource目录下添加 sonar-project.properties 文件：

sonar.issue.ignore.multicriteria=e1

sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106
sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java

We’ve just declared our very first multicriteria, named e1. We excluded the java:S106 rule for the SonarExclude class. Our definition can mix exclusions using rule identifiers and file matching patterns together*,* respectively in ruleKey and resourceKey properties preceded by the e1 name tag.

Using this approach, we can build a complex configuration that excludes particular rules across multiple files:

sonar.issue.ignore.multicriteria=e1,e2

# Console usage - ignore a single class
sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106
sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java
# Too many parameters - ignore the whole package
sonar.issue.ignore.multicriteria.e2.ruleKey=java:S107
sonar.issue.ignore.multicriteria.e2.resourceKey=com/baeldung/sonar/*.java

We’ve just defined a subset of multicriteria. We extended our configuration by adding a second definition and named it e2. Then we combined both rules in a single subset, separating the names with a comma.

6. 方法三、Maven 配置

所有Sonar分析属性可以通过Maven配置，Gradle同样类似。

6.1. Multicriteria in Maven

Returning to the example, let’s modify our pom.xml:

<properties>
    <sonar.issue.ignore.multicriteria>e1</sonar.issue.ignore.multicriteria>
    <sonar.issue.ignore.multicriteria.e1.ruleKey>java:S106</sonar.issue.ignore.multicriteria.e1.ruleKey>
    <sonar.issue.ignore.multicriteria.e1.resourceKey>
      **/SonarExclude.java
    </sonar.issue.ignore.multicriteria.e1.resourceKey>
</properties>

This configuration works exactly the same as if it were used in a sonar-project.properties file.

6.2. Narrowing the Focus

Sometimes, an analyzed project may contain some generated code that we want to exclude and narrow the focus of SonarQube checks.

Let’s exclude our class by defining sonar.exclusions in our pom.xml:

<properties>
    <sonar.exclusions>**/SonarExclude.java</sonar.exclusions>
</properties>

In that case, we’ve excluded a single file by its name. Checks will be performed for all files except that one.

We can also use file matching patterns. Let’s exclude the whole package by defining:

<properties>
    <sonar.exclusions>com/baeldung/sonar/*.java</sonar.exclusions>
</properties>

On the other hand, by using the sonar.inclusions property, we can ask SonarQube only to analyze a particular subset of the project’s files:

<properties>
    <sonar.inclusions>com/baeldung/sonar/*.java</sonar.inclusions>
</properties>

This snippet defines analysis only for java files from the com.baeldung.sonar package.

Finally, we can also define the sonar.skip value:

<properties>
    <sonar.skip>true</sonar.skip>
</properties>

This excludes the whole Maven module from SonarQube checks.

7. 总结

In this article, we discussed different ways to suppress certain SonarQube analysis on our code.

We started by excluding checks on individual lines. Then, we talked about built-in @SuppressWarnings annotation and exclusion by a specific rule. This requires us to find the rule’s identifier.

We also looked at configuring the analysis properties. We tried multicriteria and the sonar-project.properties file.

Finally, we moved our properties to the pom.xml and reviewed other ways to narrow the focus.

Persistence

REST

Security