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 to only scan the code we actually wanted to be tested. In this final article in  the series we will look at adding Sonarqube to Azure DevOps and then how to hook it into our Build process.

Adding SonarQube to Azure DevOps

The documentation for SonarQube and Azure DevOps can be found here

https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-azure-devops/

Adding SonarQube to Azure DevOps can be done through the marketplace.

Once added by an administrator you can then add a “Service Connection” for Sonar Qube through the administrative section

Once added then Sonar Scanner and Sonarqube call can be added to your build process.

Adding Sonar Scanner to your build process

When adding a new step to the build process, searching for sonar brings up all the new capabilities and options.

We need to add Prep, run and publish to the build process.

When adding the prep analysis stage we are basically running sonar scanner. In the advanced box you would add all the configurations we talked about in the previous article (from the CLI)

• 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”

although in this case we are not passing them into the CLI the -D is unnecessary.

The run code analysis step actually runs the sonar-scanner, and the publish quality gate review step allows the response from SonarQube to be understood and processed as part o fhte build process.

For more information on the plugin you can find it here

https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-azure-devops/

• Prepare Analysis Configuration task, to configure all the required settings before executing the build.
  • This task is mandatory.
  • In case of .NET solutions or Java projects, it helps to integrate seamlessly with MSBuild, Maven and Gradle tasks.
• Run Code Analysis task, to actually execute the analysis of the source code.
  • This task is not required for Maven or Gradle projects, because scanner will be run as part of the Maven/Gradle build.
• Publish Quality Gate Result task, to display the Quality Gate status in the build summary and give you a sense of whether the application is ready for production “quality-wise”.
  • This tasks is optional.
  • It can significantly increase the overall build time because it will poll SonarQube until the analysis is complete. Omitting this task will not affect the analysis results on SonarQube – it simply means the Azure DevOps Build Summary page will not show the status of the analysis or a link to the project dashboard on SonarQube.

Conclusion

As we have seen in these series of articles, adding sonarqube to your build process can help inrease the quality of your code by providing insights through analysis which woudl not otherwise haev been apparent.

It’s free to use, so why not have a play. 🙂