Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
Static code analysis is a crucial component of all modern projects. Its proper application is even more important. We decided to set up a regular check of some open source projects to see the effect of the analyzer's frequent running. We use the PVS-Studio analyzer to check projects. As for viewing the outcome, the choice fell on SonarQube. As a result, our subscribers will learn about new interesting bugs in the newly written code. We hope you'll have fun.
After all, why is it necessary to check projects regularly? If you rarely run static analysis, for example, just before the release, you may be snowed under with a great number of warnings. Looking through them all, you can miss the very significant analyzer triggerings that indicate serious errors. If you run the analysis regularly, for example, every day, then there won't be so many of those. Thus, you can easily identify crucial problems. Another reason is the cost of an error: the sooner the problem is detected, the less costly 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 have been found and fixed by the testing department. However, such fixes cost more. That is, the only right way to use static analysis is regular analysis.
As you probably know, our team often publishes articles about open source projects checks. Such articles are certainly curious to read. They bring some benefits to checked projects themselves. We always report on suspicious places to developers. However, such isolated checks have the same disadvantages as the scenario described above with an irregular code check only before the release. It's difficult to perceive a large report. Many errors end up being fixed at other levels of quality control (for example, using tests) instead of being found and fixed immediately after they hit the code.
Therefore, we decided to try a new work format with open source projects. That is a regular, daily code review of one (for a start) project. In this case, the check will be set up in a way that we'd have to view analyzer warnings covering only changed code or newly written code. It's faster than viewing the full analyzer report, and most importantly, it will allow discovering a potential error very quickly. When we find something really exciting, we'll make short notes or even write a post on Twitter.
We hope that this format will allow us to better promote more correct practices of static analysis regular use and will bring additional benefits to the open-source community.
We decided to choose the Blender project as the first project to analyze. You can tell us what additional projects you'd like us to analyze. Also, we'll describe the errors found in them.
For our task, we consider the joint effort of PVS-Studio – SonarQube tools to be the best solution for regular analysis. Further, we'll talk about the configuration of the selected tools: how to run and configure SonarQube; we'll describe how to analyze the project and how to upload the results to be displayed.
PVS-Studio can do a lot: analyze, send out notifications about warnings, and filter them. Moreover, it can also integrate into different systems to display warnings. Not only to get the check 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.
You can find more information about this application here. Now let's proceed to the deployment. SonarQube stores all the data in the database. You can use different databases, but the recommended one is PostgreSQL. Let's set it up first.
Download the latest version here. Install it and create a database for SonarQube. To do this, first, create a user named sonar. Run the following command in the psql command line:
CREATE USER sonar WITH PASSWORD '12345';You can also use pgAdmin for this and other operations. Now we need to create the database named sonarqube using the CREATE DATABASE command. It looks like this in our case:
CREATE DATABASE sonarqube OWNER sonar;The database is ready, let's start configuring SonarQube.
Download and install SonarQube. You can get the latest version here. The distribution itself is an archive. We need to unpack the archive to the C directory:\sonarqube\sonarqube-8.5.1.38104.
Then, edit the file C:\sonarqube\sonarqube-8.5.1.38104\conf\sonar.properties. We'll add there the following info on our created database:
sonar.jdbc.username=sonar
sonar.jdbc.password=12345
sonar.jdbc.url=jdbc:postgresql://localhost/sonarqubeSonarQube will see the database that we created and will start working with it. Next, you'll need to install the plugin for PVS-Studio. The plugin is in the directory where PVS-Studio is installed. It is C:\Program Files (x86)\PVS-Studio by default. We need a sonar-pvs-studio-plugin.jar file. Copy it to the directory with SonarQube C:\sonarqube\sonarqube-8.5.1.38104\extensions\plugins. You also need to download the sonar-cxx-plugin, click here to do it. At the time of writing, this is sonar-cxx-plugin-1.3.2.1853.jar. We need to copy this plugin to the C:\sonarqube\sonarqube-8.5.1.38104\extensions\plugins directory.
Now you can run SonarQube. To do this, run C:\sonarqube\sonarqube-8.5.1.38104\bin\windows-x86-64\StartSonar.bat.
Let's start setting up via the web interface. Go to the browser at sonarServer:9000. Here sonarServer is the name of the machine where SonarQube is installed.
The quality profile is a key component of SonarQube, which defines a set of rules for the codebase. The PVS-Studio plugin provides a set of rules that correspond to the analyzer 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.
Now, we need to configure the Quality Profile. To do so go to the Quality Profiles tab and click Create as shown in the picture below.
In the appeared window enter a profile name (it can be random). In our case, the name is PVS-Studio Way. Then, select the language. C++ is relevant for us now. After that, click Create.
Then go to the Rules tab, select the Repository category, and select PVS-Studio C++. Next, click Bulk Change and Activate In, in the appeared window select our created profile, that is, PVS-Studio Way.
SonarQube is set up and ready to go.
Then, we'll configure the project analysis directly using the PVS-Studio analyzer.
Download the source code with the following command:
git clone https://github.com/blender/blender.gitgenerate the project files:
make.bat full nobuildgenerate the necessary additional files, compile the build_windows_Full_x64_vc15_Release\INSTALL.vcxproj project for that.
Run the analysis with the following command
"c:\\Program Files (x86)\\PVS-Studio\\PVS-Studio_Cmd.exe" \
-t build_windows_Full_x64_vc15_Release\\Blender.sln \
-o blender.plog --sonarqubedata -rSo, we have the files blender.plog and sonar-project.properties, and we can push the results of our analysis to SonarQube. Use the sonar-scanner utility to do this.
You can download the utility here. Download the archive by the link, unzip it. For example, in our case, it is placed in the directory D:\sonar\sonar-scanner-4.5.0.2216-windows. Edit the D:\sonar\sonar-scanner-4.5.0.2216-windows\conf\sonar-scanner.properties file by adding the following line to it:
sonar.host.url=http://sonarServer:9000Where sonarServer is the name of the machine where SonarQube is installed.
Run the following command:
D:\sonar\sonar-scanner-4.5.0.2216-windows\sonar-scanner.bat \
-Dsonar.projectKey=blender -Dsonar.projectName=blender \
-Dsonar.projectVersion=1.0 \
-Dsonar.pvs-studio.reportPath=blender.plogNote that the command is called from the directory with the analysis results (blender.plog and sonar-project.properties).
To run the analysis on a project regularly, all above commands can be easily automated using a Continuous Integration server, such as Jenkins.
Regular projects analysis allows you to eliminate errors at the earliest stage when the cost of such a correction is minimal. We hope that this new format of checking open source projects and the article about it will be interesting to our readers and will diversify the "usual" articles about checking, as well as benefit the open source community. Let me remind you once again that we accept requests for the inclusion of additional projects in our regular review. We can't guarantee that we'll add a project, but we will definitely consider all your suggestions.
0
0
0
0