by Ashish Gaikwad
Steps you should take to build a healthy Angular project
Create your “Angular Fitbit” with Jenkins + SonarQube
Just like the recent introduction of wearables to track our health, the software industry has long followed the practice of monitoring the health of software projects. The most common processes applied are unit tests, integration tests, continuous integration, and code coverage.
I recently struggled a bit in trying to setup the above mentioned processes for our project, so I wrote this post to document my experience. Since TypeScript is the default language for Angular 2 projects, existing JS setups do not work.
Here are the steps to setup a Jenkins CI environment for Angular projects with code coverage using SonarQube on a headless Linux server:
- Download Jenkins and set it up on your build server. Make sure you have Java installed on it, as it is required by Jenkins. Note: Jenkins’ default configuration runs with
jenkinsuser, so you might need to set
- Once Jenkins is setup, install or make sure you have the following plugins installed from the manage plugins menu:
- Make Git, Node, and SonarQube scanner available to Jenkins. This can be done from the Global Tool Configuration menu in the Manage Jenkins menu. You can either chose to install automatically or provide the installation path for these tools. For example:
- Lastly, make Jenkins aware of the SonarQube server installation from the Configure menu in Manage Jenkins. For example:
Download SonarQube and set it up on your server. It is usually a simple package extraction on all platforms.
To enable Typescript support in SonarQube, we will use the SonarTsPlugin since SonarQube doesn’t yet have a default plugin for Typescript. Simply download the jar from the releases page of the plugin and place it in your SonarQube installations
bin folder. Restart Jenkins once. That is all.
In the Angular projects
karma.conf.js file, change/add to the
browsers:['ChromeHeadless'] . From version 60 onwards Google Chrome supports headless mode on Windows as well. So you can continue to use this setting on local machine as well, in case you work on a Windows machine in an enterprise environment (as I do). I personally prefer the headless mode only for the 1–2 seconds that it saves me.
Add the following to the
scripts section in
The above command makes sure that the build is only triggered if all the tests are successful. The
--cc flag is a short code for
--code-coverage. This flag will produce the projects coverage report in a new folder named
coverage within the project directory. The report file is named
The default configuration uses Istanbul reporter to show the code coverage report. To publish this coverage report to SonarQube server, the Jenkins SonarQube scanner plugin requires a configuration which can be added as a
sonar-project.properties file to the project or within the Jenkins project configuration. Example properties file:
With the above steps done, the project configuration in Jenkins is fairly simple.
First create a new configuration using New Item menu and then a Freestyle project.
Next in the Source Code Management section enable Git and setup the projects repo URL:
In the Build Environment section, enable the checkbox for providing the node and npm environment to the build configuration.
Then in the Build sectionn add two build steps. First Execute Shell and second Execute SonarQube Scanner.
The shell step is to run the
cibuild npm script and the latter to trigger the coverage report analysis. As mentioned above, the sonar properties can be set in the build configuration as well. Example build configuration:
That is all. Now a build can be triggered using the Build Now menu on the projects home page.
The build log will show the test results, the build logs, and the publish log to SonarQube server. It is ideal to setup remote triggers or web hooks to trigger the project build. This will ensure the stability of the project whenever there is a change in the repo.
Finally, on visiting the SonarQube server, the project details should be visible with all the metrics captured from code coverage report. Example:
This is only the first step towards creating a healthier code base. The Jenkins build can be further enhanced to create a pipeline build for better control and granular modifications.
Originally published at medium.com on September 16, 2017.