Sonarqube with Docker and Javascript, it’s the perfect combination that you can use to improve the quality of your application. Without wasting considerable time installing a lot of software and dependencies.
We can analyze an Angular project or Node.js, or any other Javascript technology.
In the previous post about sonarqube with Docker, we focus on configuring and analyzing Maven’s Java projects. However, Sonarqube already has many plugins and tools that speed up our hands-on analysis without any critical configuration.
However, to analyze Javascript code, we need to use the Sonarqube toolbox (Scanner), just a binary file (doesn’t require installation).
Prerequisites
You need to have already installed on your computer:
— Docker
— Git
So, the only software that you need to install to get started is Docker and Git. In our example, we are using all applications wrapped in a container.
Sonarqube Javascript Plugin
You don’t need to include additional plugins from the Javascript side of your project for SonarQube Javascript integration.
How to use SonarQube with Node Js
For a node js project, you must compile the Typescript code and generate the Javascript code. In our example below, we will show how to do it using an Angular project.
I will teach you how to start a Docker Container with Sonarqube, and then you can focus on the analysis.
Sonarqube Javascript Example
For our example, to learn using sonarqube with javascript, we have prepared a Hello Word built using Angular framework to make it easier to explain and go through all the steps that we need to learn. You can download the project from my GitHub repository:
git clone https://github.com/clebermasters/sonarqube-javascript.git
cd sonarqube-javascript
This project on Github does almost everything automatically.
Suppose you need more details to configure the Docker Container for Sonarqube and how to configure the sonarqube. Then, I recommend you to read our previous post, which has an outstanding level of detail about it.
When you execute the build script:
./build.sh
We will build our Angular project on this script. So, it means compiling our Typescript and generating our Javascript code. Then, later, we can give it to the Sonarqube to analyze it for us.
docker build -t www.bitslovers.com/angular:v1 .
export PROJECT=$(pwd)/angular-project
docker run --rm --name node -v $PROJECT/:/tmp/angular -t www.bitslovers.com/angular:v1 npm install
docker run --rm --name node -v $PROJECT/:/tmp/angular -t www.bitslovers.com/angular:v1 npm run build
The first step from the build.sh, we are building the Docker image that will contain the noje.js and npm. And we will use them to build the application, and that approach doesn’t need to install those applications on our computer.
In the second and third steps from the script, we effectively build the application using the Docker Image constructed before.
So, until now. No tricks, we perform npm install to download all node modules required by this project, and then you call the ng build to compile our project, like all standard node projects.
Note: This approach to using Docker to build the application is perfect for instantly testing a new version of node.js without worrying about package conflicts on your computer.
Let’s start the SonarQube
Now we can start the Sonarqube by executing the script that we have prepared to make your life easier. From the same Github project, you will find the start-sonar.sh, it’s a shell script that will automatically pull the Sonarqube image from Docker Hub and start it.
Once the sonarqube gets fully loaded, go to your web browser and type http://www.bitslovers.com:9000.
Once you have reached the login page, you can use the default Sonarqube user and password:
user -> admin password -> admin
Later, you will be prompted to change that password.
To provide access to our script to call the Sonarqube API, we need to create a Token. For more details on how to generate the token, you can check here.
Once you have the token, you need to replace it on the scan.sh script to your token on the environment variable, SONAR_TOKEN.
Also, double-check if your internal IP from the Docker Bridge adapter matches the IP from the SONAR_HOST variable. To check your IP, you can type on the terminal:
ifconfig
The interface name usually is docker0. And most docker installations will have the same IP. If you got a connection refused, try to check the IP or if port 9000 is opened on your localhost.
The SonarScanner
The SonarScanner is an open-source project that provides us with the flexibility to analyze your code using the SonarQube API. Also, it’s available for any operating system.
How does Sonar Scanner Work
How to run Sonarqube Scanner
sonar-scanner -Dproject.settings=../sonar-project.properties
The example above is the most straightforward way to run the Sonarqube Scanner. However, from our GitHub repository, we provided the script scan.sh that already does the job for you, and you don’t need to download the Sonar Scanner. Also. The script uses the official Scanner from the official Docker Image to execute the code analysis on SonarQube.
SonarScanner Download
However, you can download the zip file from the SonarQube website and extract and use it if you don’t want to use Docker.
For Linux 64-bits
You can find the binary of Sonnar Scanner for other operating systems on the official website.
For each project, we must define a sonar-project.properties file or pass it on the command line.
The main definitions that we need to specify on this file are:
sonar.projectKey=BITSLOVERS_PROJECT_V1
sonar.projectName=BITSLOVERS_PROJECT_V1
sonar.projectVersion=1.0
sonar.sources=src
sonar.exclusions=node_modules/**,src/environments/**,**/*.spec.ts,dist/**,**/docs/**,**/*.js,e2e/**,coverage/**,TLH-distributions/**,src/bsb-theme/css/**
sonar.ts.tslint.configPath=tslint.json
sonar.typescript.lcov.reportPaths=coverage/lcov.info
It would be best to define the projectKey and projectName (The name shown inside the SonarQube).
Sonar Scanner Ignore folder
The Sonar scanner provides us with one attribute that we can specify on the sonar-project.properties file with the relative path from your project.
Sonarqube Exclude Javascript Files
Like our example project, if your project requires ignoring a specific folder that needs to be skipped on the analysis process, you can include it on sonar.exclusions attribute. In our case, we are ignoring the node_modules folder that contains a massive number of files, all of which are Typescript, so we can remove it and speed up our analysis.
And finally, you can run:
./scan.sh
Sonar Scanner Not Authorized
If got an issue like this:
ERROR: Error during SonarScanner execution ERROR: Not authorized. Analyzing this project requires authentication. Please provide a user token in sonar.login or other credentials in sonar.login and sonar.password. ERROR: ERROR: Re-run SonarScanner using the -X switch to enable full debug logging
Check if you replaced the token correctly in the scan.sh shell script. Or if you are running the Scanner from the Zip file, make sure that it is a valid token, and if you pass it on the command line, like this:
sonar-scanner -Dsonar.login=yourToken
At the end of the analysis, you can check the resulting output from your it. You can copy and paste the link from the result on your web browser and review the details of the analysis.
You can navigate through the Sonarqube and check the statistics from the analysis, like the number of bugs found or vulnerabilities.
Sonar Scanner Ignore SSL
There is no way to ignore the issues regarding the certificates for HTTPS. However, we have some workaround.
Because the developers wrote the Sonar Scanner in Java language, we need to add and provide our Keystore with our self-assign certificate to use HTTPS.
Sonar Scanner Self-Signed Certificate
Suppose you need to configure a self-signed certificate for the Scanner to interact with your SonarQube instance. In that case, I suggest using the OpenJDK presented within the sonarsource/sonar-scanner-cli image. To do this, follow these steps:
- Export the cacerts file from the official sonarsource/sonar-scanner-cli image:
docker pull sonarsource/sonar-scanner-cli
docker run \
--rm \
--entrypoint cat sonarsource/sonar-scanner-cli /opt/java/openjdk/lib/security/cacerts > cacerts
Now, we need to include your certificate in the exported cacerts file. For example, suppose that your certificate file name is sonar.cer:
docker run \
--rm \
-v `pwd`:/tmp/certs \
sonarsource/sonar-scanner-cli \
bash -c 'cd /tmp/certs && keytool -keystore cacerts -storepass changeit -noprompt -trustcacerts -importcert -alias sonar -file sonar.cer'
Now we can use the cacerts by mounting it on your target container, following this example:
docker run \
--rm \
-e SONAR_HOST_URL="http://${SONAR_HOST}" \
sonarsource/sonar-scanner-cli
If you change the existing scan.sh script from our example in Github:
docker run \
--rm \
-e SONAR_HOST_URL="http://${SONAR_HOST}" \
-e SONAR_LOGIN="${SONAR_TOKEN}" \
-v "${REPO}:/usr/src" \
-v $CONFIG_FILE:/opt/sonar-scanner/conf/sonar-scanner.properties \
-v `pwd`/cacerts:/opt/java/openjdk/lib/security/cacerts \
sonarsource/sonar-scanner-cli
Where can I integrate the SonarQube analysis?
These scripts helped us install our local workspace and have a flexible solution to test our application locally. But, we need to integrate the build process and analysis of an existing Pipeline in a real scenario.
We can trigger the analysis, for example, using Jenkins or Gitlab, so it will be easy to integrate with your actual workflow to release your application.
I already had experience with Jenkins and Gitlab. And I have a different opinion about them.
I started to use Jenkins in my first project because all my application builds were already on Jenkins, and the code repository was on SVN.
My experience with Jenkins
Jenkins, it’s an excellent application for building any application language. However, Jenkins has enough features, so you always rely on set o plugins to achieve your goal and build the application. It’s not a bad thing. Instead, it adds infinite possibilities and features because the Jenkins plugin repository is vast.
The bad side of Jenkins, in my opinion:
But anybody updates your Jenkins very often. And that is a problem. So, update Jenkins; it’s a nightmare because it often breaks the plugins. And it’s pretty hard to fix the issue regarding plugin and Jenkins updates, and sometimes we need to edit the XML files manually inside the server to fix some problems when it works.
Migration to the Gitlab
Later, we decide to move all our source code to Gitlab. And, right now, it makes sense to have all pipelines together on Gitlab as well. And I loved it! Once you commit, we don’t need to switch between applications to follow up the build process, and you don’t have to manage a thousand plugins.
Conclusion
Regardless if you prefer Jenkins or Gitlab, integrating the build and analysis on the Sonarqube doesn’t require an extra plugin or configuration. Instead, you need to follow your typical workflow to build your application.
You can analyze your application on your computer for free and improve your code quality, forceless, and make your life easier.
Please leave a comment, let me know your opinion about this post, and follow me on social media.
