Angular Fitbit = Jenkins + SonarQube
Steps to healthy Angular projects.
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 process for our project and hence this post to document it. With Typescript being the default language for Angular 2 projects, existing JS setups do not work.
Following are the steps to setup a Jenkins CI environment for Angular projects with code coverage using SonarQube on a headless Linux server.
Jenkins Setup
- 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
jenkins
user, so you might need to setJAVA_HOME
for thejenkins
user. - Once Jenkins is setup, install or make sure you have the following plugins installed from the manage plugins menu.
- To complete the Jenkins setup, we must make Git, Node and SonarQube scanner available to Jenkins. This can be done from the Global Tool Configuration menu in Manage Jenkins menu. You can either chose to install automatically or provide the installation path for these tools. For example:
- Lastly we must also make Jenkins aware of the SonarQube server installation from the Configure menu in Manage Jenkins. For example:
SonarQube Setup
- 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.
Angular Project Setup
- In the Angular projects
karma.conf.js
file change/add to thebrowsers
sectionChromeHeadless
. - Example:
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, incase you work on a Windows machine in an enterprise environment (since 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 inpackage.json
file.
- 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 namedcoverage
within the project directory. The report file is namedlcov.info
. - 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 section 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 enhance to create a pipeline build for better control and granular modifications.