Configuring a SonarQube analysis with VSTS / TFS2015 vNext build

I must admit setting up a SonarQube analysis on the new build platform of VSTS / TFS2015 is a breeze compared to the previous approach.

In the old days it could take me a week to setup a TFS build server, capable of running a SonarQube analysis including unit testing and code coverage analysis. One had to deploy all kinds op OSS tools for unit testing and code coverage analysis or customize the build process template to transform the Visual Studio Test Results to an XML file SonarQube would accept.

All that is completely gone. You don’t even necessarily have to add a sonar-project.properties file to your Visual Studio Solution although you could. However there was one challenge which took me half a day to finally resolve. And for this reason I reckoned it would be a good idea to share the solution for this challenge with this post.

-Note. Unfortunately due to a server crash the images of this post got lost. Restore of the images is still in progress. –

Preparation

Obviously you need a SonarQube server up and running to publish the SonarQube analysis results. The SonarQube server requires the C#  version 5.0 plugin, a plugin with is compatible with SonarQube 4.5.2+ (LTS). If you are on an older SonarQube version, you will be required to upgrade.

You also need your SonarQube Endpoint configured on TFS and have a build agent available with the capabilites java, msbuild, visualstudio and vstest. If you can’t find out how to do this, just drop me a comment and I’ll explain this in another blog post.

Basic approach

To get started just add the following build steps to your definition as shown on the picture below:

  1. SonarQube for MSBuild – Begin Analysis
  2. Visual Studio Build
  3. Visual Studio Test
  4. SonarQube for MSBuild – End Analysis
SonarQube build process overview
SonarQube build process overview

Configuring SonarQube MSBuild – Begin Analysis Step

One could say this build step is the new and improved replacement of the sonar-project.properties file, which was used to configure sonar-runner. With just 5 settings you are all set.

SonarQube Server
In the SonarQube Server section the SonarQube Endpoint has to be selected from the top down list. If you don’t know how to configure the endpoint, just drop me a comment.

SonarQube Project Settings
In the next section you configure your project key, project name and project version. The Project Key is the technical identification of your project in SonarQube. In my example I used com.capgemini.DevOps. The project name is your common name for your project, in my case DevOpsDemo. And the Project Version, is obviously the current version of your solution you are working on, in my case 1.0.

Advanced
My biggest challenge with the SonarQube analysis was getting the Visual Studio Unit Test results published in SonarQube. To my surprise, although the unit test coverage results are uploaded with no additional settings, the unit test results themselves are not. I suspect this to be an undocumented minor bug in the SonarQube for MSBuild – End Analysis task, currently on version 1.0.36.

To workaround this issue it is required to set the following Additional Setting:

/d:sonar.cs.vstest.reportsPaths="$(Common.TestResultsDirectory)\*.trx"

Common.TestResultsDirectory is a one of the default build variables available to tweak your build process to the actual environment the build agent is running in. This variable will be set to the local path on the agent where the test results are created.

Configuring Visual Studio Build Step

Just configure this step as you see fit. For a SonarQube analysis no special configuration is required.

Configure Visual Studio Test Build Step

Again you can basically configure this step as meets your unit test requirements. However for the SonarQube analysis you want to enable the option “Code Coverage Enabled”.

Configure SonarQube for MSBuild – End Analysis STEP

Although this is the build step which actually executes the SonarQube analysis, the build step itself requires no configuration, except for the step has to be Enabled, which is the default setting.

Configure General Settings

As already mentioned in the preparation section above a SonarQube analysis requires the capabilites java, msbuild, visualstudio and vstest from the build agent.

To assure you build ends up at an agent with these capabilities you need to add these four capabilities to the Demands section on the build definition’s General tab with the type “exists”

Setting the required Agent capabilities.
Setting the required Agent capabilities.

Conclusion

With the settings described above you are basically all set to run your SonarQube analysis. Obviously a build definition needs some more configuration with regard to Options, Repository, Triggers, General settings and Retention, but I consider these out side of the current scope of this blog post. If you want to know about these, just drop me a comment.

Please follow and like us:
RSS
Follow by Email
Facebook
Google+
https://www.dsec.nl/2016/04/configuring-a-sonarqube-analysis-with-vsts-tfs2015-vnext-build/
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *