Use SonarScanner to statically scan Maven projects on Rainbond

Static scanning of code is a very common code quality assurance method. This scanning can not only detect defects in the code, but also apply various industry best practices. Azimuth improvement. Among various code scanning solutions, SonarQube is the most well-known and widely used. Various continuous integration solutions have their own ways to integrate into SonarQube for static scanning of code.

Today we introduce a method for statically scanning Java Maven projects during the Rainbond source code build process based on SonarScanner.

Introduction to SonarScanner For Maven

Use SonarScanner for Maven to perform code static scanning on Maven projects, which is the default scanner officially recommended by SonarQube. Just add the specified parameters to the mvn command to integrate the scanner and analyze code vulnerabilities during the build process.

Example command:

 mvn clean verify sonar:sonar -Dsonar.login=myAuthenticationToken

In the actual execution process, myAuthenticationToken will be replaced by a token generated by an actual user in SonarQube.

Integrate into the continuous integration chain

After understanding how SonarScanner for Maven works, we can try to integrate the process of code scanning into Rainbond's automated continuous integration chain. The final effect we hope to achieve is to automatically trigger the construction of the project after the code is submitted, scan and analyze the code during the construction process, and generate corresponding reports.

The whole process can be summarized into the following stages:

1. Developers submit code to the code repository, triggering the entire continuous integration chain.
2. The code repository uses Webhook to call Rainbond's Openapi interface, triggering the corresponding service component to build itself.
3. While Rainbond automatically builds the corresponding service components, it triggers the SonarScanner scan work and sends the scan results to the SonarQube service.
4. The SonarQube service analyzes the scan results and generates a code detection report.
5. Developers read code inspection reports and learn about improvements.
6. The developer improves the code according to the report, submits it again, and returns to step 1 to form a closed loop of continuous integration.

Next, from the perspective of practical operation, the above continuous integration chain will be implemented bit by bit based on Rainbond.

Preconditions

The continuous integration chain including code scanning introduced in this article is based on the Rainbond cloud native management platform. Therefore, users need to prepare an available Rainbond environment by themselves, which needs to be connected to the public network to prepare for using the open source application store.

Building SonarQube

In addition to the Rainbond cloud native application management platform, the code repository and SonarQube service also need to be prepared. For the former, we choose to use Gitlab, while the SonarQube service can be installed directly based on the open source application store. At present, the open source application store provides the 8.9.9 (lts) version of SonarQube for users to install with one click.

Users only need to select the open source application store in the application market interface of Rainbond, search sonarqube to find the corresponding installation entry:

Click Install, select the installation location, and you can install the SonarQube service and Postgresql database to the specified location with one click.

Access SonarQube's external service port to enter its login page. The default username and password are: admin / admin .

If you don't have your own code repository, you can follow a similar process to install Gitlab based on the open source app store.

Generate AuthenticationToken

In SonarQube, each user can generate AuthenticationToken as a communication token, SonarScanner communicates with the SonarQube service through this token to verify its identity.

Here, we generate ---33011634444d6e18f27f5d55fcd2b639--- for the AuthenticationToken Administrator user specifically for scanning Java Maven projects.

After logging in as the admin user, switch to the Security tab on the My Account page to generate a Token.

Copy the record created AuthenticationToken , it will only appear once!

Build a Maven project from Gitlab

Rainbond can connect with Gitlab code repository based on Oauth2.0, it is very convenient to choose to build projects in Gitlab, and automatically configure the code to build automatically.

Refer to the document: Rainbond and Gitlab docking

A standard Java Maven project code already exists in the Gitlab I'm using. Click to build a component based on source code, select the docked Gitlab, and then you can search for the project you want to deploy.

In the process of creating a component, you can turn on the switch for automatic build, which is equivalent to configuring the switch for automatic build triggered by code push.

After clicking to confirm the creation, the detection of the code language will be completed. At this time, enter the advanced settings and click the deployment properties on the left. We need to make some advanced settings to adapt to SonarScanner.

The settings that need to be made include: declaring the address of the SonarQube service, AuthenticationToken of the corresponding account, and adding a build command with a code scanning step.

Configure Settings.xml

The general configuration of SonarScanner, including the SonarQube service address, and AuthenticationToken can be configured into the Settings.xml global configuration for use when building a Java Maven project.

When Rainbond builds for a Java Maven type project, it provides Settings.xml for the entry configuration that takes effect globally. In Advanced Settings - Deployment Properties, you can click Manage Maven Configuration to edit the default Settings.xml. Here we have provided a default configuration, we need to add the following configuration in xml format to define the SonarQube service address, and AuthenticationToken .

 <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <pluginGroups>
    <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
  </pluginGroups>
  <profiles>
    <profile>
      <id>sonar</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <sonar.host.url>
          http://9000.grba63fe.duaqtz0k.17f4cc.grapps.cn
        </sonar.host.url>
        <sonar.login>
          c1041c2b4ac2e89d1fe3f5fa5bb5971bc8dc85b7
        </sonar.login>
      </properties>
    </profile>
  </profiles>
</settings>

Of course, users can also create a dedicated Settings.xml configuration, in my environment, I named this configuration sonar-scanner . The global configuration only needs to be defined once.

Modify the build command

SonarScanner For Maven performs code scanning by adding specific parameters to the mvn command.

In the Maven build command input box, modify the command as follows:

 clean verify sonar:sonar   -Dsonar.projectName=Maven-demo -Dsonar.projectKey=Maven-demo  install

For each different project, you need to customize the value of -Dsonar.projectName -Dsonar.projectKey . The former defines the name of the project in the SonarQube service, and the latter defines the unique ID of the project.

Start your first build

The currently used SonarScanner requires a JDK version higher than 1.8. Here we choose OpenJDK 11 because this release is another long-term support release after 1.8.

By now, in the deployment properties, the build source information page should look like this:

Click Confirm to create, you can jump to the page and enter the first construction process. After a while, the first build will be completed, and the code will be automatically packaged and put online. Check the build log to understand the analysis steps in the build process:

Access the address mentioned in the log, you can view the new report in the SonarQube service.

Code Analysis Report

Developers can refer to the reports provided by the SonarQube service to understand the current code problems. Industry best practices to fix bugs are given in the SonarQube report. Taking the project I used as an example, 2 bugs and 4 security issues were scanned. Take one of the bugs as an example, SonarQube gives very detailed hints, including reasonable code hints.

Update iteration code

According to the analysis report, after fixing the code, the developer submits the code again, and includes keywords in the code submission information to automatically trigger the construction of the project and a new round of code scanning.

The @deploy contained in the Commit Message is the keyword that triggers the automatic build. For more information on Rainbond automatic builds, please refer to the documentation Rainbond Automatic Builds

Wait for the project to automatically build and review the analysis report again to determine if the bug has been resolved.

Reviewing the operational records of components in Rainbond, you will see the difference between manual and automatic builds.