Search code examples
javamavensonarqubesonar-runnerpre-commit

How to use sonarQube from Maven to gather incremental analysis prior to commit


Question: How to use sonarQube from Maven to gather incremental analysis prior to commit?

Background: We are using SonarQube 4.1.2 to perform analysis on a java project that is built with Maven. We have installed the Issues Report plugin 1.1 onto the server.

I have enabled the incremental reporting in the build console and can see that the incremental data is being supplied properly from within the Continuous Integration server using the maven command: 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

There is a related Maven profile:

<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>

From the Continuous Integration CI server logs, I can see the incremental reporting on the console as expected:

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

When this is called from development machine for incremental analysis with the command: 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

I get an incremental report that has many more issues that would be expected for the modified code. Curiously, the number here is also greater than the total number of issues for the project as measured on the sonarQube server:

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

    +65058 issues

    +42709 major
     +2287 minor
    +20062 info

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

Reference Links I have been consulting the following links as part of my investigation:

Three options for pre-commit analysis http://www.sonarqube.org/three-options-for-pre-commit-analysis/

Analysis vs. Preview vs. Incremental Preview in SonarQube http://www.sonarqube.org/analysis-vs-preview-vs-incremental-preview-in-sonarqube/

Issues Report Plugin http://docs.sonarqube.org/display/SONAR/Issues+Report+Plugin

CodeHaus Sonar Maven Plugin http://mojo.codehaus.org/sonar-maven-plugin/plugin-info.html

Update (2014/07/16) Noticed this thread [http://sonarqube.15.x6.nabble.com/Incremental-run-mode-td5024228.html]. This explains that the incremental is working off a hash of the file to determine which files to analyze.

The project I am working on has generated code which sonar has not been told to ignore. I am postulating that this is causing additional churn (in addition to be just a bad idea to scan the machine-generated code). To explore this theory, I am adding -Dsonar.exclusions=com/generatedpackage/**/*.java to the command.

Update (2014/07/17)

By specifying the generated sources in the sonar.exclusions, the number of violations detected for "incremental" analysis was reduced. Once these were all account for, the number of issues/violations came into alignment with the number of issues I introduced to verify the process locally. To simplify the maintenance of this, I then simplify suppressed the metrics for all generated files using the following pattern: file:**/generated*/**

For uniformity, I was able to specify this within the root POM of the project under analysis.

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

As cited above, the sonar Qube forum thread explained that incremental analysis will only analyze files whose hash does not match the hashed files on the sonar Qube server.


Solution

  • The key to using this successfully was two-fold: 1) Ensure the Issues Report plugin is installed on the sonarQube server 2) Specify the sonar.exclusion to ensure that generated sources are excluded

    With this in hand and a "sonar" profile, the user needs to only add this "sonar" profile and the sonar:sonar goal to the maven command

    This changes:

    mvn clean install -P myProfile
    

    To:

    mvn clean install sonar:sonar -P myProfile,sonar 
    

    The maven profile could bind the sonar goal to the verify phase so as to omit the need to specify the goal when profile is added. I elected to not bind the plugin to afford slightly more flexibility.

    This was sufficient to enable users to verify the incremental code.