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:

1. How to set up a sample SonarQube server in Azure
2. Setting up a unit test sample locally
3. How to set up sonar-scanner and connect it to SonarQube
4. Configuring Sonar Scanner to test only our code

Introduction

In the previous article we saw how to set up a sonar scanner locally and run a scan of our out of the box sample project. The code was a little smelly and there were some bugs found. In this article we are going to look at where those bugs come from and why they are not relevent to our solution. By the end we will have a working Sonar Scanner correctly scanning our code and running tests.

Looking at the bugs and smells

Part of the reason why I left this in here was to see some of the beauty of SonarQube and the information it provides us. How does it know there are bugs? What smells?

Looking at our report closer we can click on the project and then the Bugs and we see the following bugs.

There are a couple of important things to note here:

1. The bugs are coming from the JEST folder
2. It checked .css as well as .js

Clicking on the See Rule we can see why it decided this was a bug.

SonarQube runs off pre-built rules (like a linter does) and determines that the quality of the code is a “bug” because it breaks a rule. This is really interesting and drives us to create better code – which is ultimately to goal of using the capability!

looking at the bug shows you where in the code – pretty cool eh?

You can poke around with the code fails as well, that’s not why we are here – but it is fun to look around.

These two files are in the JEST folder which is not “our” code and therefore there is no need to test it. So let’s configure the scanner to look at “our” code.

Configuring sonar scanner via CLI

If you are running sonar-scanner locally you can change the sonar.properties file to add some of the default values. In this case we are going to coninue to pass the parmeters in through the CLI because we are not going to be able to do that when we go to the CI/CD pipeline in Azure DevOps.

We are adding new parameters

1. updating sonar.sources to point to our code
2. adding sonar.typescript.lcov.reportPaths so that SonarQube can use the coerage reports created by Jest
3. adding sonar.tests so that we are specific as to where our test are located
4. adding sonar.exclusions so that we are not assessed for coverage on our tests, which would be silly
5. adding sonar.test.inclusions to identify which files are our “tests”

• sonar-scanner.bat
  -D”sonar.projectKey=IceCreamShop”
  -D”sonar.host.url=http://xominosonarqube.azurewebsites.net”
  -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″
  -D”sonar.sources=src/webparts/iceCreamShop”
  -D”sonar.tests=src/webparts/iceCreamShop”
  -D”sonar.typescript.lcov.reportPaths=jest/lcov.info”
  -D”sonar.exclusions=src/webparts/iceCreamShop/test”
  -D”sonar.test.inclusions=**test.ts,**test.tsx”

Running the sonar-scanner.bat command again we get some slightly different results this time……

MUCH better 🙂

Loking at the code coverage section we can see that there are some additional files which have been added that are not really what I wanted to test.

What isn’t covered?

Looking into the files which failed is really helpful because you can visually see where the lines with no coverage are !!

Conclusion

In this article we have see how to configure sonar scanner to scan our files and not the dependancies. In the next article we will see how to connect to SonarQube from Azure DevOps