sonar java
8.8.0.37665
Этот проект Sonarsource является анализатором кода для Java Projects, чтобы помочь разработчикам производить чистый код. Информация об анализе функций Java доступна здесь.
Чтобы предоставить обратную связь (запросите функцию, сообщите об ошибке и т. Д.) Используйте форум сообщества Sonar. Пожалуйста, не забудьте указать язык (Java!), Версия плагина и версию Sonarqube.
Если у вас есть вопрос о том, как использовать плагин (а документы вам не помогают), мы также рекомендуем вам использовать форум сообщества.
Чтобы запросить новую функцию, пожалуйста, создайте новую ветку на форуме сообщества Sonarqube. Даже если вы планируете реализовать его самостоятельно и отправить обратно сообществу, сначала запустите новую ветку, чтобы быть уверенным, что мы можем использовать его.
Чтобы отправить вклад, создайте запрос на привлечение для этого репозитория. Пожалуйста, убедитесь, что вы следуете нашему стилю кода, и все тесты проходят (все чеки должны быть зелеными).
Если у вас есть идея для правила, но вы не уверены, что каждому ему это нужно, вы можете реализовать пользовательское правило, доступное только для вас. Обратите внимание, что для того, чтобы помочь вам, мы настоятельно рекомендуем сначала следовать учебному пособию «Правила 101», прежде чем погрузиться непосредственно в реализацию правил с нуля.
Хотели бы вы работать над этим проектом на полный рабочий день? Мы нанимаем! Проверьте https://www.sonarsource.com/hiring
Запускать тесты локально следуйте этим инструкциям.
Вам нужна Java 22 , чтобы построить проект, а Java 17 запустить интеграционные тесты (ITS).
Java 17 может использоваться для создания и тестирования всех модулей, за исключением того, что под java-checks-test-sources , которые требуют Java 22 .Java 22 может использоваться для создания и тестирования всех модулей, за исключением its , которые требуют Java 17 из -за несовместимости SQ.Чтобы создать плагин и запустить его модульные тесты, выполните эту команду из корневого каталога проекта:
mvn clean install
Продолжительные модульные тесты в IDE могут возникнуть в некоторых проблемах из -за того, как проект построен с Maven. Если вы видите что -то вроде этого:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
Попробуйте удалить природу Maven модуля «JDT».
Чтобы запустить интеграционные тесты, вам нужно будет создать файл свойств, подобный указанному ниже, и установить URL -адрес, указывающий на его местоположение в переменной среды с именем ORCHESTRATOR_CONFIG_URL .
# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE
orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties
# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository
Например, переменная ORCHESTRATOR_CONFIG_URL устанавливается как:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Прежде чем запустить ITS, убедитесь, что ваша переменная среды Maven_home установлена.
«Испытание на здравомыслие» - это тест, который запускает все проверки по всем файлам исходного тестирования, не учитывая результат анализа. Это проверяет, что правила не сбоятся ни по какому файлу в наших источниках теста. По умолчанию этот тест исключен из сборки. Чтобы запустить это:
mvn clean install -P sanity
«Тест плагина» - это комплекс интеграционных тестов, который проверяет функции плагина, такие как показатели метрики, покрытие и т. Д., Чтобы запустить его:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Примечание для внутренних участников: чтобы также выполнить тесты, которые зависят от издания Sonarqube Enterprise, использование:
mvn clean install -Pit-plugin
«Правящий тест» - это набор интеграционных тестов, который запускает анализ большой кодовой базы, сохраняет проблемы, созданные плагином в файлах отчетов, а затем сравнивает эти результаты с набором ожидаемых проблем (хранящиеся в виде файлов JSON).
Чтобы запустить тест, сначала убедитесь, что подмодулы проверены:
git submodule update --init --recursive
Затем убедитесь, что переменная среды JAVA_HOME установлена для выполнения правящих тестов и указывает на вашу локальную установку JDK 17. Неспособность сделать это принесет несоответствия с ожидаемыми результатами.
Из папки its/ruling , запустите правящие тесты:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
Примечание для внутренних участников: чтобы также выполнить тесты, которые зависят от издания Sonarqube Enterprise, использование:
mvn clean install -Pit-ruling
Этот тест дает вам возможность изучить проблемы, созданные каждым правилом, и убедиться, что они то, что вы ожидаете. Любое реализованное правило, вероятно, поднимает проблемы в нескольких проектах, которые мы используем в качестве правящей базы кода.
Для недавно реализованного правила это означает, что первая сборка, скорее всего, потерпит неудачу, вызванную различиями между ожидаемыми результатами (без каких -либо значений для нового правила) и новыми результатами. Вы можете проверить эти новые проблемы, выполнив поиск файлов, названных в честь вашего правила ( squid-SXXXX.json ) в следующей папке:
/path/to/project/sonar-java/its/ruling/target/actual/...
Для существующих правил, которые изменены, вы можете ожидать некоторых различий между «фактическим» (от нового анализа) и ожидаемыми результатами. Тщательно просмотрите изменения, которые показаны, и соответствующим образом обновите ожидаемые ресурсы.
Все файлы json содержат список строк, проиндексированные файлом, объясняя, где находятся проблемы, поднятые конкретным правилом. Если/когда все выглядит хорошо для вас, вы можете скопировать файл с фактическими проблемами, расположенными по адресу:
its/ruling/target/actual/
В каталог с ожидаемыми проблемами:
its/ruling/src/test/resources/
Например, используя команду:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Тесты в модуле Autoscan предназначены для выявления различий между проблемами, которые Java Analyzer может найти с и без Bytecode. Цель здесь состоит в том, чтобы определить и исправить потенциальные FPS и проверить ожидаемые FN, которые будут отображаться в автоматическом анализе SonarCloud.
Запуск этого теста может быть разбит через 2 шага:
Убедитесь, что модуль java-checks-tests-sources был составлен (т.е. файлы .CLASS в java-checks-tests-sources/target/ ).
Всего, иди и запустите модуль java-checks-tests-sources модуль и запустите:
# Use java 22!
mvn clean compile Чтобы запустить тесты, перейдите в папку its/autoscan и запустите:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE Артефакты, произведенные во время выполнения теста, будут найдены в its/autoscan/target/actual . Вы захотите сравнить результаты, полученные в Autoscan-Diff-By Rules
Для получения более подробной информации вы можете сравнить различия между результатами, найденными с байт -кодом и без байт -кода, сравнив две соответствующие папки:
В зависимости от найденных результатов, вам может потребоваться обновить основную правду. Ожидаемые результаты перечислены в SRC/Test/Resources.
Вы можете отлаживать его, добавив -Dmaven.binary=mvnDebug в качестве опции при запуске тестов. Это приведет к тому, что Analyzer JVM будет ждать, пока отладчик будет прикреплен, прежде чем продолжить.
Copyright 2012-2024 Sonarsource.
Анализаторы Sonarqube, опубликованные после 29 ноября 2024 года, включая исправления патчей для предыдущих версий, опубликованы в соответствии с лицензией, доступной для источника Sonar, версии 1 (SSALV1).
См. Индивидуальные файлы для деталей, в которых указана лицензия, применимая к каждому файлу. Файлы, подлежащие SSALV1, будут отмечены в их заголовках.
