Как использовать sonarQube от Maven для сбора инкрементного анализа перед фиксацией

Вопрос: как использовать sonarQube от Maven для сбора инкрементного анализа перед фиксацией?

Общие сведения. Мы используем SonarQube 4.1.2 для анализа проекта Java, созданного с помощью Maven. Мы установили плагин Issues Report 1.1 на сервер.

Я включил добавочные отчеты в консоли сборки и вижу, что добавочные данные правильно предоставляются с сервера непрерывной интеграции с помощью команды maven: mvn org.codehaus.mojo:sonar-maven-plugin:2.3.1:sonar -P sonar -Dsonar.java.target=1.7 -Dsonar.java.source=1.7 -Dsonar.profile=MyProfileName -Dsonar.branch=branchID

Существует связанный профиль Maven:

<profile>
    <id>sonar</id>
    <activation>
            <activeByDefault>false</activeByDefault>
    </activation>     
    <properties>
        <sonar.hostname>mySonarHostName</sonar.hostname>
        <sonar.host.url>http://${sonar.hostname}:9000</sonar.host.url>
        <sonar.jdbc.url>jdbc:oracle:thin:@${sonar.hostname}:1521/sabrixdb</sonar.jdbc.url>
        <sonar.jdbc.username>dbusername</sonar.jdbc.username>
        <sonar.jdbc.password>dbpassword</sonar.jdbc.password>
        <sonar.jdbc.driver>oracle.jdbc.driver.OracleDriver</sonar.jdbc.driver>

        <sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
        <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    </properties>
</profile>

Из журналов сервера непрерывной интеграции CI я вижу добавочные отчеты на консоли, как и ожидалось:

build   14-Jul-2014 15:40:37    [INFO] [15:40:37.699] 
build   14-Jul-2014 15:40:37    
build   14-Jul-2014 15:40:37    -------------  Issues Report  -------------
build   14-Jul-2014 15:40:37    
build   14-Jul-2014 15:40:37            +3 issues
build   14-Jul-2014 15:40:37    
build   14-Jul-2014 15:40:37            +3 major
build   14-Jul-2014 15:40:37    
build   14-Jul-2014 15:40:37    -------------------------------------------
build   14-Jul-2014 15:40:37    
build   14-Jul-2014 15:40:37

Когда это вызывается с машины разработки для инкрементного анализа с помощью команды: mvn org.codehaus.mojo:sonar-maven-plugin:2.3.1:sonar -Dsonar.profile=MyProfileName -Dsonar.branch=branchID -Dsonar.analysis.mode=incremental -Dsonar.host.url=http://mySonarHostName:9000 -Dsonar.issuesReport.html.enable=true -Dsonar.issuesReport.console.enable=true -Dsonar.dynamicAnalysis=reuseReports

Я получаю добавочный отчет, в котором есть гораздо больше проблем, которые можно было бы ожидать для измененного кода. Любопытно, что число здесь также больше, чем общее количество проблем для проекта, измеренное на сервере sonarQube:

-------------  Issues Report  -------------

    +65058 issues

    +42709 major
     +2287 minor
    +20062 info

-------------------------------------------

Справочные ссылки В рамках моего расследования я просматривал следующие ссылки:

Три варианта анализа перед фиксацией http://www.sonarqube.org/three-options-for-pre-commit-analysis/

Анализ, предварительный просмотр и дополнительный предварительный просмотр в SonarQube http://www.sonarqube.org/analysis-vs-preview-vs-incremental-preview-in-sonarqube/

Подключаемый модуль отчетов о проблемах http://docs.sonarqube.org/display/SONAR/Issues+Report+Plugin

Плагин CodeHaus Sonar Maven http://mojo.codehaus.org/sonar-maven-plugin/plugin-info.html

Обновление (16.07.2014) Заметил эту тему [http://sonarqube.15.x6.nabble.com/Incremental-run-mode-td5024228.html]. Это объясняет, что инкрементальный метод работает с хэшем файла, чтобы определить, какие файлы анализировать.

Проект, над которым я работаю, сгенерировал код, который эхолоту не было приказано игнорировать. Я предполагаю, что это вызывает дополнительный отток (помимо того, что это просто плохая идея сканировать сгенерированный машиной код). Чтобы исследовать эту теорию, я добавляю -Dsonar.exclusions=com/generatedpackage/**/*.java к команде.

Обновление (17.07.2014)

За счет указания сгенерированных источников в sonar.exclusions было уменьшено количество выявляемых нарушений при «инкрементальном» анализе. Как только все это было учтено, количество проблем/нарушений совпало с количеством проблем, которые я ввел для проверки процесса на месте. Чтобы упростить обслуживание этого, я затем упростил подавление метрик для всех сгенерированных файлов, используя следующий шаблон: file:**/generated*/**

Для единообразия я смог указать это в корневом POM анализируемого проекта.

<sonar.exclusions>file:**/generated*/**</sonar.exclusions>

Как упоминалось выше, в ветке форума Sonar Qube поясняется, что инкрементный анализ будет анализировать только те файлы, хэш которых не совпадает с хешированными файлами на сервере Sonar Qube.


java maven sonarqube pre-commit sonar-runner
person user2832162    schedule 16.07.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Ключом к успешному использованию этого является два аспекта: 1) Убедитесь, что плагин Issues Report установлен на сервере sonarQube 2) Укажите sonar.exclusion, чтобы убедиться, что сгенерированные источники исключены.

Имея это в руках и профиль «сонара», пользователю нужно только добавить этот профиль «сонара» и цель сонара: сонар в команду maven.

Это меняет:

mvn clean install -P myProfile

To:

mvn clean install sonar:sonar -P myProfile,sonar

Профиль maven может привязать цель сонара к фазе проверки, чтобы исключить необходимость указывать цель при добавлении профиля. Я решил не привязывать плагин, чтобы обеспечить немного большую гибкость.

Этого было достаточно, чтобы пользователи могли проверить инкрементный код.

person user2832162    schedule 25.07.2014
comment
Вы случайно не сталкивались с этой проблемой? stackoverflow.com/questions/29099614/ - person Zhenya; 18.03.2015