This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:
- How to set up a sample SonarQube server in Azure
- Setting up a unit test sample locally
- Setting up Sonar Scanner and connecting to SonarQube
- How to run a sonar-scanner review manually
- How to integrate the code review into your Azure DevOps build and release process.
In the previous article we saw how to clone and load up the PnP react-jest-testing sample and run an initial test. I am not going to go into the advantages of unit testing your code – but if you want more information on how and why check out these excellent MVPs and their blog posts on the subject.
In this article we are going to set up Sonar Scanner to analyze the code locally and then connect it to our SonarQube server.
Setting up Sonar Scanner
Sonar Scanner can be downloaded and installed from here. You have to extract it and add the bin directory path to your environmental variable (way easier in Windows 10) to get it to work.
Once that is up and running there are a number of steps which we have to go through to turn our npm test into something which will create reportable files for SonarQube. The process of testing is the same, the only difference is the output and how it is handled.
Setting up a SonarQube Project Key
Within our SonaarQube server create a new project – in this case I called it IceCreamShop for the sake of simplicity
From that I get a the ability to generate a project key
and from there we can continue and get instructions on how to run the sonar scanner for this project.
The information at the bottom is the important part for us:
- sonar-scanner.bat -D”sonar.projectKey=IceCreamShop” -D”sonar.sources=.” -D”sonar.host.url=http://xominosonarqube.azurewebsites.net” -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″
Put another way this is running the CLI for sonar-scanner and passing variables which are not directly configured in the sonar scanner properties config file (which we will come to later)
-D”sonar.sources=.” #run the scan from the root directory
-D”sonar.host.url=http://xominosonarqube.azurewebsites.net” #SonarQube server for the results to be posted to
-D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″ #the project key to associate the scan with
So let’s go ahead and run that in our project and see what happens…….
— NOTE —
On a windows machine you must run visual studio code as adminstrator – otherwise it may not be able to create and delete folders as part of the test running process.
If you see an error around – INFO: Sensor SonarCSS Rules [cssfamily] – you must have the sonarJS plugin 5.2.1 installed.
The result is not pretty – for many reasons but let’s look at what we have for now, for this article. As you can see from the output below there are a number of errors and issues reported.
If we look at our SonarQube server though we can see an analyzed project.
Looks like we have some smelly code, some bugs and some code debt – this is a really nice feature of SonarQube and why it is helpful in Code Quality reviews. We dont have any code coverage though which is odd……..
As we will come to see in the next article. The code is not all that smelly, it is actually our configuration. 🙂