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:
- SonarQube for MSBuild – Begin Analysis
- Visual Studio Build
- Visual Studio Test
- SonarQube for MSBuild – End Analysis
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”
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.