SonarQube includes the concept of quality gates and these gates allow you to answer questions about the quality of the code being analyzed. They come as sets of Boolean conditions and can be based on the usual Sonar metrics including blocker issues, code coverage on new code, reliability rating, etc.
Here are the default settings:
More info here: https://blog.sonarsource.com/quality-gates-shall-your-projects-pass
Based on the outcome you can by default notify users, but in most cases I would argue that you should display alerts on developer team dashboards or integrate the result with the release process. For C# (and most other builds going through MSBuild) Sonar provides a VSTS / TFS extension that performs several tasks including publishing the Quality Gate Status as part of SonarQube Analysis report:
Unfortunately all this good stuff depends on MSBuild and we cannot use this for our JavaScript/ npm/ gulp or grunt builds.
This post combines the concepts found in two earlier writings and extend on this scenario, by adding quality gates in SonarQube and have the Visual Studio Team Services reflect the outcome on the dashboard.
JavaScript Unit Tests with Visual Studio Team Services
Better together: SonarQube, TypeScript and Code Coverage
Setup
Our setup is a combination of the ones described in the earlier posts. We use three docker images to run our setup for this post:
- VSTS Agent (microsoft/vsts-agent): this runs our build locally using Selenium and uploading the test results to SonarQube;
- Selenium (selenium/standalone-chrome): runs our unit test using a real Chrome browser;
- SonarQube (sonarqube): this container will analyze our code and coverage results.
We could create a Docker Compose file, but for the purpose of this demo we can work with the individual images. If you are new to Docker make sure you have met all the requirements for running containers on your favorite platform. See https://docs.docker.com/engine/docker-overview for more information.
Since we need all of the machines to be able to communicate with each other, I like to create an isolated network first where we add our named images:
docker network create vsts-net
We can then run our Selenium container on this network:
docker run \ -d -p 4444:4444 \ --shm-size=2g --name webdriver \ --net vsts-net selenium/standalone-chrome
And our private build agent:
docker run \ -e VSTS_ACCOUNT= \ -e VSTS_TOKEN= \ -it --name agent \ --net vsts-net microsoft/vsts-agent
And eventually our SonarQube instance:
docker run \ -d -p 9000:9000 -p 9092:9092 \ --name sonarqube \ --net vsts-net sonarqube
Important parts:
- Everything runs on the default ports, but you can change them as you like;
- The VSTS container needs your VSTS accountname and an Access Token which you can create on visualstudio.com;
Demo
For this blogpost we will use this demo project and have VSTS build it: https://github.com/yuriburger/quality-gate-demo
Important: in the sonar-project.properties file there is a sonar.login that you need to update with your own SonarQube User Token. See https://docs.sonarqube.org/display/SONAR/User+Token for more information.
Our build is simple as it just runs the available npm build steps in the correct order.
- Npm Install: the usual node modules installer;
- Npm run build: just runs the TypeScript Compiler;
- Npm run test: this will run our Karma test;
- Npm run sonar: this will run the SonarQube analyzer and upload the results.
If we queue this build, hopefully everything works out and we have a successful build 
If we now navigate to SonarQube (on http://localhost:9000 if you did not change the port) we should see our project and since we have 100% code coverage in our demo project, the gate is green!
Good job!
/Y.