Trigger SonarQube from Jenkins

You can log in to SonarQube with the default administrator account; both username and password are admin. In a real-world scenario, you should absolutely change those, but we are going to use them as is. If you do decide to change them, be sure to change them in the configuration up ahead as well:

Like Jenkins, SonarQube alone does not do much. It needs a runner that does all of the heavy work. There are specific runners for certain platforms, but the generic runner will suffice in most cases:

sudo apt-get update
sudo apt-get install unzip
wget https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-2.8.zip
unzip sonar-scanner-2.8.zip
sudo mv sonar-scanner-2.8/ /opt/
rm sonar-scanner-2.8.zip

These commands download a zip file containing a runner; unzip it, move the unzipped folder to the opt folder, and remove the original zip. We need to make some configuration changes as well. In the /opt/sonar-scanner-2.8/conf/sonar-scanner.properties file, uncomment sonar.host.url, sonar.jdbc.username, sonar.jdbc.password, and sonar.jdbc.url under PostgreSQL. Also, add the two lines sonar.host.username=admin and sonar.host.password=admin.

Those steps are exactly the same in Windows, except you can do them using your mouse instead of keyboard. I have unzipped the Sonar Scanner in C:\, just like SonarQube.

Now, we need to register SonarQube and the Sonar Scanner in Jenkins. To do that, we first need to install the SonarQube plugin. Once you have done that, you can register the SonarQube server under Manage Jenkins and then Configure System. Find SonarQube servers and add one. The least you have to do is give it a name (such as ciserver). Right now, Jenkins cannot connect to SonarQube and you will notice that the username and password fields are disabled. Log in to SonarQube and head over to Administration (in the top right menu). Now, go to Users in the Security dropdown. Now, click on the little icon in the Tokens column of the Administrator row. Create a new token, call it Jenkins, and be sure to copy that token. You can now paste that token in Jenkins, in the Server authentication token field. Also, make sure to uncheck Help make Jenkins better by sending... at the bottom, unless you really want to make Jenkins better.

After that, we need to register the Sonar Scanner. Go to Manage Jenkins and then go to Global Tool Configuration. Find SonarQube Scanner and add a scanner. Name it Local, disable Install automatically, and set /opt/sonar-scanner-2.8/ as SONAR_RUNNER_HOME.

If everything went well, you have now successfully configured Jenkins to work with SonarQube. Of course, we want to test it and see it with our own eyes. First, we will need a little code file that SonarQube can analyze. In your Git project, create a new file and call it something.js. Put the following code in it and then push it to Git:

var something = 'something'
if (something)
    console.log('something');

Now that we have some code that SonarQube can analyze, go back to our Jenkins project. On the project page, click Configure to change the configuration of your build (which will be active immediately after saving). Add a build step, Execute SonarQube Scanner, and, in Analysis properties put the following configuration:

sonar.projectKey=test
sonar.projectName=Test
sonar.projectVersion=1.0

sonar.sources=.

sonar.exclusions=*.txt

This is basically saying create a project with the ID test and display name Test on version 1.0. The sources property includes all the files in the current folder, but we ignore all the files with a txt extension. Run the job and head over to SonarQube (you will notice a SonarQube link on your project page; it does not work). In SonarQube, view your projects on the upper-left menu and be sure to filter all (the default is your favorites, which is none at the moment). Click on the project to get a detailed report. You will see one vulnerability issue, bringing your security rating to B. If you click on it, you will get details on what is wrong, why it is wrong, and how you should fix it; that is pretty awesome. In this case, the console.log statement is a security risk.

Unfortunately, we had expected at least one more issue. The first line of our code is missing a semicolon at the end. That may prove disastrous if we are going to minify the code! On the top left menu, go to Quality Profiles. Here, you can create and modify the sets of rules. Our project used the Sonar way profile. Click on the little button behind the profile and choose Activate More Rules. Find Statement should end with semicolons and activate it. You can set a severity for the issue. I made it a critical issue. Once it is activated, you can return to your project and you will see it now has a code smell and one minute technical debt:

It is possible to make a Jenkins build fail when your technical debt rises or when you write blocking issues (which is even worse than critical). This is what CI is about: check in code and get instant feedback.