1. Обзор
Во время наших сборок мы можем использовать различные инструменты, чтобы сообщать о качестве нашего исходного кода. Одним из таких инструментов является SonarQube , выполняющий статический анализ кода.
Иногда мы можем не согласиться с возвращенными результатами. Поэтому мы можем захотеть исключить некоторый код, который был неправильно помечен SonarQube.
В этом коротком уроке мы рассмотрим, как отключить проверки Sonar. Хотя можно изменить набор правил на сервере SonarQube, мы сосредоточимся только на том, как управлять отдельными проверками в исходном коде и конфигурации нашего проекта.
2. Пример нарушения
Давайте посмотрим на пример:
public void printStringToConsoleWithDate(String str) {
System.out.println(LocalDateTime.now().toString() + " " + str);
}
По умолчанию SonarQube сообщает об этом коде как о запахе кода из-за нарушения правила java :S106 :
Однако давайте представим, что для этого конкретного класса мы решили, что ведение журнала с помощью System.out допустимо . Может быть, это легкая утилита, которая будет работать в контейнере и не нуждается в целой библиотеке журналирования только для входа в стандартный вывод .
Следует отметить, что также можно пометить нарушение как ложноположительное в пользовательском интерфейсе SonarQube. Однако если код будет анализироваться на нескольких серверах или если после рефакторинга строка переместится в другой класс, то нарушение появится снова.
Иногда мы хотим сделать наши исключения в репозитории исходного кода, чтобы они сохранялись.
Итак, давайте посмотрим, как мы можем исключить этот код из отчета SonarQube, настроив проект.
3. Использование // НОСОНАР
Мы можем отключить одну строку кода, поставив // NOSONAR в конце :
System.out.println(
LocalDateTime.now()
.toString() + " " + str); //NOSONAR lightweight logging
Тег // NOSONAR в конце строки подавляет все проблемы, которые могут возникнуть в связи с этим. Этот подход работает для большинства языков, поддерживаемых SonarQube .
Нам также разрешено оставлять некоторые дополнительные комментарии после NOSONAR, объясняющие, почему мы отключили проверку.
Давайте двинемся дальше и рассмотрим специфичный для Java способ отключения проверок.
4. Использование @SuppressWarnings
4.1. Аннотирование кода
В Java мы можем исключить проверки Sonar с помощью встроенной аннотации @SuppressWarnings .
Мы можем аннотировать функцию:
@SuppressWarnings("java:S106")
public void printStringToConsoleWithDate(String str) {
System.out.println(LocalDateTime.now().toString() + " " + str);
}
Это работает точно так же, как подавление предупреждений компилятора. Все, что нам нужно сделать, это указать идентификатор правила, в данном случае java:S106 .
4.2. Как получить идентификатор
Мы можем получить идентификатор правила, используя пользовательский интерфейс SonarQube. Когда мы смотрим на нарушение, мы можем щелкнуть Почему это проблема? :
Он показывает нам определение. Отсюда мы можем найти идентификатор правила в правом верхнем углу:
5. Использование sonar-project.properties
Мы также можем определить правила исключения в файле sonar-project.properties , используя свойства анализа .
Давайте определим и добавим файл sonar-project.properties в наш каталог ресурсов:
sonar.issue.ignore.multicriteria=e1
sonar.issue.ignore.multicriteria.e1.ruleKey=java:S106
sonar.issue.ignore.multicriteria.e1.resourceKey=**/SonarExclude.java
Мы только что объявили наш самый первый мультикритерий с именем e1 . Мы исключили правило java:S106 для класса SonarExclude . Наше определение может смешивать исключения, используя идентификаторы правил и шаблоны сопоставления файлов , соответственно, в свойствах ruleKey и resourceKey , которым предшествует тег имени e1 .
Используя этот подход, мы можем создать сложную конфигурацию, которая исключает определенные правила для нескольких файлов:
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/foreach/sonar/*.java
Мы только что определили подмножество multicriteria . Мы расширили нашу конфигурацию, добавив второе определение и назвав его e2 . Затем мы объединили оба правила в одно подмножество, разделив имена запятыми.
6. Отключить с помощью Maven
Все свойства анализа можно также применить с помощью свойств Maven . Подобный механизм также доступен в Gradle .
6.1. Мультикритерии в Maven
Возвращаясь к примеру, давайте изменим наш 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>
Эта конфигурация работает точно так же, как если бы она использовалась в файле sonar-project.properties .
6.2. Сужение фокуса
Иногда анализируемый проект может содержать некоторый сгенерированный код, который мы хотим исключить и сузить фокус проверок SonarQube.
Давайте исключим наш класс, определив sonar.exclusions в нашем pom.xml :
<properties>
<sonar.exclusions>**/SonarExclude.java</sonar.exclusions>
</properties>
В этом случае мы исключили один файл по его имени. Проверки будут выполняться для всех файлов, кроме этого.
Мы также можем использовать шаблоны сопоставления файлов. Давайте исключим весь пакет, определив:
<properties>
<sonar.exclusions>com/foreach/sonar/*.java</sonar.exclusions>
</properties>
С другой стороны, используя свойство sonar.inclusions , мы можем попросить SonarQube проанализировать только определенное подмножество файлов проекта:
<properties>
<sonar.inclusions>com/foreach/sonar/*.java</sonar.inclusions>
</properties>
Этот фрагмент определяет анализ только для java-файлов из пакета com.foreach.sonar .
Наконец, мы также можем определить значение sonar.skip :
<properties>
<sonar.skip>true</sonar.skip>
</properties>
Это исключает весь модуль Maven из проверок SonarQube.
7. Заключение
В этой статье мы обсудили различные способы подавления определенного анализа SonarQube в нашем коде.
Мы начали с исключения проверок на отдельных линиях. Затем мы рассказали о встроенной аннотации @SuppressWarnings и исключении по определенному правилу. Это требует от нас найти идентификатор правила.
Мы также рассмотрели настройку свойств анализа. Мы попробовали мультикритерий и файл sonar-project.properties .
Наконец, мы переместили наши свойства в файл pom.xml и рассмотрели другие способы сузить фокус.