Automatic Code Review with SonarQube and Jenkins Part 2/2

---

---

Subsequent to the first part of this post you can improve your code quality by implementing an automated code review system to your projects. You only need to perform a few modifications to SCM-Manager, Jenkins and SonarQube. In the first part of this article we already showed you the necessary configuration of SCM-Manager and Jenkins. Now, in the second part we will show you the necessary modifications to integrate SonarQube to the automated process.

Code Reviews with SonarQube

With SonarQube you can extend the automatic code review system. You can define code metrics that you want your project to be checked for. For each metric you can define limits for warnings and errors. In addition to the configuration of the first part, Jenkins will also mark builds as failed if there are errors in the SonarQube analysis. Failed builds will not be published by to the master branch of the SCM-Manager repository.

If the build in Jenkins succeeds, the analysis by SonarQube is invoked. In case there are no violations of the defined metrics the code modifications get merged to the master branch in the repository in SCM-Manager. If there are violations Jenkins will mark the build as failed and the changes will not be published.

Generally speaking you need to modify the permissions to each repository in SCM-Manager and to each project in Jenkins. In SonarQube you add the alerts to your set of rules.

Implementation for SonarQube and Jenkins

To extend the code review process by connecting SonarQube there are only a few modifications to the Jenkins project and to SonarQube itself necessary.

SonarQube Configuration

First thing we need to do with SonarQube is to install the Build Breaker plugin. Go to the “Settings → Update Center” screen and select the Available Plugins tab. In the section Integration you will find Build Breaker. This plugin allows SonarQube to mark a build in Jenkins as failed if certain conditions are met.

After the installation of the plugin you need to reload the application in Tomcat Manager. When SonarQube is available again go to the Quality Profiles screen and select your set of rules (e.g. Sonar way). After that navigate to the Alerts tab. There you can add the metrics that you want to use.

For your alerts you can select from various metrics like “Number of issues”, “Size of classes” or “Comments percentage”. In our example we selected “Coverage” and set the limit for warning to less than 75% and for error to less than 65%. Therefore the build will break whenever the test coverage drops below 65%.

It is up to you to select the metrics you want to use and to find appropriate limits. If they are too restrictive it will be difficult to advance in the project. If they are too weak they are expendable.

Jenkins Configuration

In Jenkins you only need to change the order of the Post-build Actions. It is important that Sonar is located above Git Publisher. Otherwise the changes to the code would be published no matter what the results of the SonarQube analysis is. We want to get the results from the SonarQube analysis before we publish the changes to the master branch.

All previous modifications to Jenkins from part 1 stay untouched.

Automated code reviews improve quality

By implementing this automated code review process you immediately get feedback about whether or not your code can be build, the success of your unit tests and the compliance with your own code metrics and key figures. In the beginning it will take some time to find a good balance between restriction and redundancy of your metrics. Over time they can be adjusted to improve the quality of your code.

Try the automated code review yourself

If you don’t have a Cloudogu EcoSystem of your own yet, learn more about it.

Note: On Oct. 8th we adapted the post to Cloudogu EcoSystem

---

---