Just for fun: the PVS-Studio team came up with the idea to monitor the quality of some open source projects
Static code analysis is an important component of all modern projects. Even more important is its correct application. We decided to organize a regular review of some open source projects to see the effect of frequent running of the analyzer. We use the PVS-Studio analyzer to check projects, and we will view the results using SonarQube. So our subscribers will learn about new interesting bugs in the newly written code. We think it will be funny.
Why is it important to check projects regularly? If you rarely run static analysis, for example, just before the release, you can “drown” in a large number of warnings and, looking through all of them, you can miss the really important analyzer triggers that indicate serious errors. If you run the analysis regularly, for example, every day, then the number of triggers will not be so large, and you can easily identify really important problems. Another reason is the cost of the error: the sooner the problem is discovered, the cheaper it is to fix it. For example, if you run static analysis just before the release, then by that time most of the bugs will be found by the testing department and fixed, but such fixes are more expensive. That is, regular analysis is the only correct way to use static analysis.
As you probably know, our team often publishes review reports for open source projects. Such articles are certainly interesting to read, and they bring certain benefits to the checked projects themselves – we always send a report on the found suspicious places to the developers. However, such single project checks have the same drawbacks as the scenario described above with irregular code checks only before release. A large report is difficult to understand, and many errors that could be found and fixed immediately after they enter the code are already fixed at other levels of quality control (for example, using tests).
Therefore, we decided to try a new format for working with open source projects – a regular, daily check of the code of one (for the beginning) project. At the same time, this check will be configured in such a way that every day you will need to look at the analyzer triggers only on the changed or newly written code – this is much faster than viewing the full analyzer report, and, most importantly, it will allow you to very quickly detect a potential error. When we come across something really interesting, we will make small notes about it or even just tweet.
We hope that this format will allow us to both better popularize a more correct practice of regular use of static analysis, and will bring additional benefits to the open source community.
As the first project for analysis, we decided to choose a project Blender… You can write to us what additional projects you would like, so that we also regularly analyze and talk about the errors found in them.
Setting up regular analysis
For our task, we consider the combination of PVS-Studio tools – SonarQube as the most optimal solution for regular analysis. Further in the article we will talk about setting up the selected tools: how to start and configure SonarQube, describe how to analyze the project and load the results for display.
Why we chose SonarQube
PVS-Studio can do a lot: analyze, send notifications about warnings found, filter them, but it can also integrate into different systems to display warnings. In order not only to receive the test results, but also to additionally test more PVS-Studio operating modes, we decided to try to configure the display of results for our task in SonarQube.
Details about the capabilities of this application can be read here… We will proceed with the deployment. SonarQube stores all data in a database. You can use different databases, but PostgreSQL is the recommended one. Let’s set it up first.
PostgreSQL setup
Download the latest version here… Install the database, create a database to use SonarQube. To do this, first create a user named sonar – run the following command on the psql command line:
CREATE USER sonar WITH PASSWORD '12345';
You can also use pgAdmin for this and other operations. Let’s create a database named sonarqube using the CREATE DATABASE command, in our case like this:
CREATE DATABASE sonarqube OWNER sonar;
The database is ready, let’s start configuring SonarQube.
SonarQube setup
Download and install SonarQube. The latest version can be taken from here… The distribution kit itself is an archive. Unpack the archive into the C: sonarqube sonarqube-8.5.1.38104 directory.
Let’s edit the file C: sonarqube sonarqube-8.5.1.38104 conf sonar.properties. Add the following data for our created database there:
sonar.jdbc.username=sonar
sonar.jdbc.password=12345
sonar.jdbc.url=jdbc:postgresql://localhost/sonarqube
SonarQube will see the database we have created and start working with it. Next, you need to install the plugin for PVS-Studio. The plugin is located in the directory where PVS-Studio is installed, by default it is C: Program Files (x86) PVS-Studio. We need a sonar-pvs-studio-plugin.jar file. Copy it to the SonarQube directory C: sonarqube sonarqube-8.5.1.38104 extensions plugins. You also need to download the sonar-cxx-plugin plugin, this can be done here… At the time of this writing, this is sonar-cxx-plugin-1.3.2.1853.jar. Copy this plugin to the C: sonarqube sonarqube-8.5.1.38104 extensions plugins directory.
Now you can start SonarQube by running C: sonarqube sonarqube-8.5.1.38104 bin windows-x86-64 StartSonar.bat.
Let’s start configuring via the web interface. Go to the browser at sonarServer: 9000, where sonarServer is the name of the machine where SonarQube is installed.
Quality Profile setting
The quality profile is a core component of SonarQube that defines a set of rules for the codebase. The PVS-Studio plugin provides a set of rules that correspond to the analyzer’s warnings; we can add all of them to the quality profile or disable any rules, if necessary. According to the configured quality profile, SonarQube will display or not display warnings after analyzing our code.
Let’s configure the Quality Profile by going to the Quality Profiles tab and clicking the Create button, as shown in the figure below.
In the window that appears, enter the profile name (it can be arbitrary), in our case PVS-Studio Way, and select the language – C ++ is relevant for us now. After that press the Create button.
Then go to the Rules tab, select the Repository category and select the PVS-Studio C ++ item in it. Next, click the Bulk Change and Activate In buttons, in the window that appears, select our created profile, that is, PVS-Studio Way.
SonarQube is configured and ready to go.
Analysis
Next, let’s configure the analysis of the project directly using the PVS-Studio analyzer.
Download the sources with the following command:
git clone https://github.com/blender/blender.git
then let’s generate project files:
make.bat full nobuild
we will generate the necessary additional files, for this we will compile the build_windows_Full_x64_vc15_Release INSTALL.vcxproj project.
Let’s start the analysis with the command
"c:\Program Files (x86)\PVS-Studio\PVS-Studio_Cmd.exe"
-t build_windows_Full_x64_vc15_Release\Blender.sln
-o blender.plog --sonarqubedata -r
As a result of the analysis, we have the blender.plog and sonar-project.properties files, and we can push the results of our analysis into SonarQube. To do this, you need to use the sonar-scanner utility.
Sonar scanner
The utility can be downloaded from here… The archive is downloaded from the link, it must be unzipped, for example, in our case, into the D: sonar sonar-scanner-4.5.0.2216-windows directory. Let’s edit the file D: sonar sonar-scanner-4.5.0.2216-windows conf sonar-scanner.properties by adding the line:
sonar.host.url=http://sonarServer:9000
Where sonarServer is the name of the machine where SonarQube is installed.
Let’s run the following command:
D:sonarsonar-scanner-4.5.0.2216-windowssonar-scanner.bat
-Dsonar.projectKey=blender -Dsonar.projectName=blender
-Dsonar.projectVersion=1.0
-Dsonar.pvs-studio.reportPath=blender.plog
Note that the command is called from the directory with the analysis results (blender.plog and sonar-project.properties).
To regularly run analysis on a project, all the commands described above can be easily automated using a Continuous Integration server, for example, Jenkins.
Conclusion
Regular project analysis allows you to eliminate errors at the earliest stage, when the cost of such a fix is minimal. We hope that such a new format for checking open source projects and the story about it will be of interest to our readers and dilute the “usual” articles about checking, and will also benefit the open source community. Let me remind you once again that we accept applications for the inclusion of additional projects in the regular review – we do not promise that we will add a project, but we will definitely consider all your proposals.
If you want to share this article with an English-speaking audience, please use the translation link: Evgeniy Ovsyannikov. Just for Fun: PVS-Studio Team Came Up With Monitoring Quality of Some Open Source Projects.
