SonarQube enables developers to track code quality, which helps them to ascertain if a project is ready to be deployed in production. Further, it allows developers to continuously inspect the code, perform automatic reviews and run analysis to find code quality issues.

Furthermore, SonarQube provides a lot of other features, including the ability to record metrics, evolution graphs etc. It has inherent options to perform automated analysis and continuous integration utilizing tools such as Jenkins, Hudson, etc. In this blog, we will explore the process of creating pipeline scripts for SonarQube integration. Here are the steps.

• Log in to your configuration domain (e.g. https://jenkins.domain.com).
• Go to the specific profile in Jenkins (Here, in this case, it is the root project).
• To configure a Sonar job, select ‘New Item’ available on the left side panel in Jenkins.

• In the subsequent screen provide a job name. Click on ‘Pipeline’ option, if you intend to run a Pipeline, else select the ‘Maven’ option.

• Click on ‘OK’ button to provide configuration details. Now, let us take a look at the various links available on the left side of the screen.
  • Changes – The ‘Changes’ option enables developers to change the name of a job.
  • Build Now – This feature allows developers to run a job in Jenkins. It starts to read the code from the repository and builds the code.
  • Configure – This option enables developers to read the code from the Git/SVN repository.

SonarQube Integration with Jenkins

Here is the complete process of SonarQube integration with Jenkins.

• Click on ‘Configure’ option, which will redirect developers to the following screen, enabling them to read the code from the Git/SVN repository.
• In the General tab, developers can provide a Pipeline name and log build details, such as how many days the logs should be kept etc. In the ‘Days to keep builds’ field, enter the number of days.

• If using a Git repository, select Git project, else proceed to the next tab.
• The next tab is ‘Office 365 Connector’, this screen is used to run a build based on parameters.
• The option ‘This project is parameterized’ is one of the parameters that developers should have a brief idea. It is used to build a job based on branches. In situations, where developers want to run a job based on development/master branches, they can define it using this option else, the job will run as default.

• Build Trigger Section – This option can be utilized, if developers are keen to run the jobs based on specific time intervals e.g. once a day or twice a day. Additionally, jobs can be scheduled to run automatically by using the ‘Build periodically’ option.
• Pipeline Section – The pipeline section is the core feature of a job; it reads data/code from a specific repository in GIT/SVN. However, developers need to specify the script file, which is available in the GIT/SVN application.

• Here is the pipeline script that needs to be added to the Jenkins file.

• Add the following plugin details in the build.gradle/pom.xml file (if it is maven):

a) Sonar Plugin

b) Apply plugin: ‘org.sonarqube’

c) Add SonarQube Server Details:

• Once the configuration is complete, developers can build job manually or automatically. This can be activated using the option ‘Build Now’ available on left side panel of the screen.

• After the build process is complete in Jenkins, it reads the code and compares each line, if it observes any violations of rules, it sends a report to the sonar server. Here is a sample snapshot of the SonarQube report.

Developers can view a list of issues on the SonarQube dashboard. If they are interested to find out what went wrong in their code base, all they have to do it simply click on specific links (numbers above). This action will redirect developers to specific code, where they can fix the issues.

Here is an example, below is a test class, where we have created a sample Java class.

If you observe, Code Smells count is 3, clicking on number 3 will redirect developers to the following screen on a Sonar server. Further, it will show/suggest the vulnerability based on the rule.

In our code ‘testService.java’, we have used a sample system.out .print ln( ) method. In Sonar server, a rule is defined that mentions use logger instead of system.out.

The below method main() is kept empty in ‘my testservice.java class’, as can be observed, SonarQube is recommending to comment on this method since this method is empty. Similarly, it shows other issues in the code. 

Hope this post serves the purpose of providing insights on SonarQube integration, if you have any specific questions or comments, please feel free to post your comments.

The post SonarQube Integration with Jenkins Using Pipelines appeared first on Tech Chronicles.

Configuring Jenkins To Build WebGoat

We’re going to scan a known vulnerable webapp, WebGoat, which is an OWASP project used for learning basic web penetration testing skills and vulnerabilities. A good scanner should find a lot of things!

A quick note: We were initially going to use Mutillidae, another vulnerable app written in PHP. However we couldn’t find any good open source PHP Static analyzers that would catch the vulnerabilities.

Anyway, let’s get on with Jenkins. Navigate in your browser to http://localhost:8080 and enter the admin password shown in the terminal running docker. Go ahead and install the default plugins (for a deployed instance, I would recommend only installing plugins you will actually use) and create your first admin user.

WebGoat requires Java 11 to build, which Jenkins won’t install automatically. Head over to the main page -> Manage Jenkins -> Global Tool Configuration. There are two sections here we will update now: JDK installation and Maven installations. We need to add a link to a Java 11 installer – we used https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz and we can use the default maven. Your config should look like this:

We sometimes see Jenkins have trouble installing a JDK this way if more than one JDK is installed in the system. If this is the first one, there should be no problems.

Finally, we have to set the JAVA_HOME variable. In the Jenkins -> Manage Jenkins -> Configure System menu, enable environment varaibles and set JAVA_HOME equal to /var/jenkins_home/tools/hudson.model.JDK/openjdk11/jdk-11.0.1/.

Now let’s create a pipeline for WebGoat and make sure it builds successfully. Back on the main page choose new item -> freestyle project.

The initial setup is pretty simple:

• Add Webgoat to the various github setting locations (https://github.com/WebGoat/WebGoat/)
• Set the target branch to */develop
• Create a maven build step (“Invoke top level maven targets”) and give it the command “clean install”

Here is the full pipeline configuration:

Try running it and making sure that everything builds successfully.

Adding SonarQube and DependencyCheck

SonarQube setup & security

We already have a SonarQube instance running, we just need to link and configure Jenkins to use it. Log in to http://localhost:9000 and use the default sonarQube login of admin/admin.

Although this is only for practice, I still want to secure our SonarQube instance, so do the following:

• Change the admin password
• Go to administration-> security and turn on “Force user authentication”
• Create a new user for Jenkins.
• Log into the new user, go to the profile -> security section, and generate a token. Copy this for later use.

Finally, create a project named “webgoat” with your jenkins user.

Configure the plugins for Jenkins

We will need two new plugins for jenkins. In the Jenkins home page, go to Mange Jenkins -> Manage Plugins. On the Available tab find and select “OWASP Dependency-Check Plugin” and “SonarQube Scanner for Jenkins”. Install them without restarting.

Back on the Jenkins home, go to Manage Jenkins -> Global Tool Configuration. You should see a new option for SonarQube Scanner. Add an installation here (I just chose the latest from Maven Central) and save.

Finally, head over to Jenkins -> Manage Jenkins -> Configure System and add a sonarqube instance. The URL with our docker container is http://sonarqube:9000 and the token should be the one you saved while setting up the Jenkins user in SonarQube. Here is my setup:

One other thing I had to do to get SonarQube working properly. For some reason I couldn’t completely determine, the SonarQube startup script was truncating the JAVA_HOME path incorrectly, causing errors during the pipeline. To solve this, log into the docker container manually and update the sonar script to the proper JAVA_HOME.

$ docker exec -it secure_pipeline_jenkins_1 bash
jenkins@2ea0acb5905d:/$ cd /var/jenkins_home/tools/hudson.plugins.sonar.SonarRunnerInstallation/sonarqube
jenkins@2ea0acb5905d:~/tools/hudson.plugins.sonar.SonarRunnerInstallation/sonarqube$ head bin/sonar-scanner
#!/bin/sh
#
# SonarQube Scanner Startup Script for Unix
#
# Optional ENV vars:
#   SONAR_SCANNER_OPTS - Parameters passed to the Java VM when running the SonarQube Scanner
#   SONAR_SCANNER_DEBUG_OPTS - Extra parameters passed to the Java VM for debugging
#   JAVA_HOME - Location of Java's installation

JAVA_HOME="/var/jenkins_home/tools/hudson.model.JDK/openjdk11-remote/jdk-11.0.1"

Add SonarQube and DependencyCheck to the pipeline

Now we can add these to our pipeline and start scanning with every build.

In the pipeline created earlier, add two new build steps – Invoke Dependency-Check analysis and Execute SonarQube Scanner. In the SonarQube scanner, add the configuration settings required – the project key and name should match the project you created in SonarQube.

sonar.projectKey=webgoat
sonar.projectName=webgoat
sonar.projectVersion=1.0
sonar.language=java
sonar.java.binaries=**/target/classes
sonar.exclusions=**/*.ts

I am excluding the TypeScript files above since we did not setup Node or a JS build step for our project. In a real project, we would want to ensure that they were also scannable.

In the DependencyCheck advanced section, check to generate HTML reports as well for easier viewing.

Here is my full pipeline configuration now:

Kick off a build and make sure it runs correctly. Afterwards, you should be able to see results.

Viewing Reports

If all runs successfully, logging into SonarQube will show you security scan details (with plenty of findings!) and the pipeline can show you the dependencyCheck results in the workspace -> dependency-check-report.html file.

You can and should at this point consider additional SonarQube plugins (or other SAST tools) that are specifically for your languages and frameworks.

Breaking the Build

We want to know when something isn’t working right at the build phase. SonarQube gives us this for free with the plugin (you should see a nice red ERROR tag under the SonarQube Quality gate) but DependencyCheck requires one more configuration.

Add a post-build check for “Publish Dependency Check Results” and expand the advanced tabs. Just add some threshold data and the build will fail or be marked unstable according to the rules set.

Here  is our final pipeline configuration, fully expanded.

Final Thoughts

Getting a CI/CD pipeline running with some basic security checks can be done within a few minutes. This will help keep your published artifacts in better shape and ensure the team has an opportunity to learn about security issues as soon as they emerge.

The post Creating a Secure Pipeline: Jenkins with SonarQube and DependencyCheck appeared first on Tech Chronicles.

When you have software development projects that you are building and running on Red Hat OpenShift you are probably testing them out locally with Minishift, getting the deployment correct, testing source-to-image or running your Dockerfile builds with environment variables to ensure your CI/CD pipeline is ready to roll. Or maybe you are testing out platforms or containers and kubernetes and you want to get a good developer experience when doing it. You also could be testing out this DevOps thing people have been talking about for years and years.

One other thing to remember is the “Sec” part of DevSecOps: Sec = security. In my case, I use SonarQube locally and on my platform as part of my “Sec” steps to scan my projects and look for errors, vulnerabilities, bad coding practices, and the like. This post is to show how to setup SonarQube via a template within OpenShift (and Minishift) and call it from your Jenkins pipeline.

Setup Minishift

First things first, you need Minishift on your machine. I use a Mac for all my development so I used brew to install the latest Minishift executable. You can see other ways to setup Minishift here. I also use VirtualBox for my virtual machine driver for Minishift. I have a script that runs this for doing all my local Minishift development work that adds the vm-driver for VirtualBox, memory of 10GB, and disk-size of 40GB. I also run with the profile flag and save off the VM under a specific name so I can keep track of it. All personal preferences of course and you can run minishift -h to see the options. Figure out the options you wish to use and run minishift start with those options. It will pull down images, start the system, and give you information on how to log in. When that is up and running we are ready to setup SonarQube.

Minishift Command

Optional: Enable the Admin-User AddOn

This is optional but I like doing this locally. I enable the admin-user addon for Minishift. This lets you log in with ‘god’ rights. You can run minishift addon enable admin-user and then run minishift addon apply admin-user to do this. Once enabled and then applied you can login with admin/admin and see all the inner workings of Minishift and get a glimpse of what OpenShift has under the covers. There are other addons you can see by running the command minishift addons list as well. (Che is the other one I am testing out.)

Setup the SonarQube Project

Now that we have Minishift setup, you can go to the URL that was listed when you started it in the terminal window and login with admin/admin. Click the Create Project button on the top right and enter sonarqube (all lower case) for the Name field and SonarQube for the Display Name field. You can enter a description if you like to ensure you know what it is later when you look at the project listings.

Add the SonarQube project on Minishift

Click the Create button and then click the SonarQube link that is created for you in the project listings. You will get to the blank screen for a Minishift project. From here you can deploy images, import deployment settings (we are doing this one), import other definitions in YAML format as well as select from templates in the catalog. I encourage you to see how you can import other templates, create your own templates for faster deployments, and get more familiar with this interface if you are going the OpenShift way.

I was inspired by the OpenShift Demos GH repo on SonarQube however I needed to update my image and persist data differently. So I went a different route. Not better or worse just different.

Now that you are in the SonarQube project click the “Import YAML / JSON” button and copy and paste this deployment from this GitHub repo. Click the Create button on the bottom right and ensure “Process the Template” is checked. Click Continue to get a listing of parameters. I will go into more detail later on these settings of saving data for the extensions (plugins), logs, temp space as well as the PostgreSQL database space.

You can adjust the space if you wish or just leave the defaults. I usually leave the database password field blank and it generates its own when I am doing local development.

When all is ready click the Create button and then the Close button and you will see a BUNCH of things were created. (Note the default SonarQube login is also admin/admin. If you keep this up you will want to change it OR link in oAuth, GitHub login, or Keycloak.)

What did we just do? Well we create a pod with a PostgreSQL image that when run exposes port 5432 internally to the project. We created a pod with a SonarQube 7.4-community image that when run exposes port 9000 through the https://sonarqube-sonarqube.x.x.x.x route. We have a database connection from SonarQube to PostgreSQL. And we have 5 areas of storage setup to persist data for these containers that are run: database data, SonarQube data, SonarQube extensions/plugins, SonarQube logs, and SonarQube temp space.

Do we need all of these? Maybe not if you want to write into the container and not keep it if it restarts. I do not like doing that. So I do it this way. Feel free to use and adjust to your will.

SonarQube 7.4 Community Edition setup in Minishift

Let’s Dive In!

To get more familiar with what our YAML file actually did we need to explore a little. We setup 2 deployments inside our project, one for each application. One application is SonarQube itself and we are using the image from DockerHub for that. The other application is PostgreSQL and OpenShift comes with that image already. So we just used it. If you click the Applications menu on the left and then Deployments you can see the 2 deployments we have. Click further on the links to see what each one has setup. For each deployment OpenShift will list #1, #2, #3 for the number of the deployment you have running. We just did this so you should see the #1 hyperlinked. Click on it to get something like the below image.

What you can see from the highlighted region are those storage listings, persistent volumes and persistent volume claims in Minishift language. This is telling OpenShift that for those areas of my container running (i.e. /opt/sonarqube/extensions) I want you to save that data in OpenShift to persist it. And as the container comes up or is redeployed mount this path inside the container for reuse. I am simplifying it however that is the gist of what this is doing. You also can see these Mounts going against the Storage listing under the Storage menu on the left. I tried to match the names to have them make sense for you.

Log into SonarQube

Go back to the Overview section of your project and you will see the https://sonarqube-sonarqube.x.x.x listing. This is the Route exposing a URL to the internal SonarQube container running. We only have a route for SonarQube. We do not need an external route for PostgreSQL as only SonarQube has to talk to it. Click that link and log in with admin/admin to ensure you can get to SonarQube. If it starts a tutorial click Skip this tutorial. You should get into SonarQube and see a screen like below. Now get to work!

Use Jenkins in projects to scan code with SonarQube

Having SonarQube is great and all only if you use it. I have an example microservice API project in dotnet core 2.1 that you could put into a brand new project and then use its deployment file to deploy 3 pods: Jenkins, the database, and the API. Then log into Jenkins, approve the OpenShift login, and see how Jenkins works within OpenShift. For SonarQube to work you need to add the SonarQube plugin on the Manage Jenkins → Manage Plugins page and restart. Then go into the Manage Jenkins → Configure System and setup the SonarQube plugin with the name if the server (i.e. SonarQube-Server), the internal-to-Openshift URL (i.e. http://sonarqube.sonarqube.svc), and a generated token from your account page so you can push scan results from the Jenkins process. You also could fork this project linked above and play around to get more familiar. The best way to learn is to do!

The steps on how to use SonarQube with Jenkins are here and are also all over Google.com and StackOverflow.com as well. To use that project linked above you have to load up some Jenkins slave images and update your Jenkinsfile to use them.

Advanced: .NET Core Sonar Scanner Jenkins Slave

There is a .Net Core SonarQube Scanner Jenkins slave image on this other repo that you can import by using the YAML files and importing into the ‘openshift’ project in OpenShift. You can use this project here to create in OpenShift to test it out. The Jenkins slave setup in the Jenkins Configure System screen will need to match the name of the labels in the Jenkinsfile. For now get used to SonarQube and see what you can do!

The post Setup SonarQube in OpenShift for scanning projects via Jenkins appeared first on Tech Chronicles.

Sonarqube is a great tool for source code quality management, code analysis etc. This is the most widely used tool for code coverage and analysis.

Install and  Configure Sonarqube on Linux

This guide will help you to set up and configure sonarqube on Linux servers (Redhat/Centos 7 versions) on any cloud platforms like ec2, azure, compute engine or on-premise data centers. Follow the steps given below for the complete sonarqube configuration.

Sonarqube requirements

1. Server with minimum 2GB/1 vcpu capacity
2. PostgreSQL version 9.3 or greater.
3. OpenJDK 11 or JRE 11
4. All sonarquber process should run as a non-root sonar user.

You can find the official requirement doc here.

Update: MySQL for Sonarqube is depricated

Prep the Server With Required Softwares

Step 1: Update the server.

Step 2: Install wget & unzip

Step 3: Install java 11

Step 4: Login as root and execute the following commands.

Setup PostgreSQL 10 Database For SonarQube

Step 1: Install PostgreSQL 10 repo.

Step 2: Install PostgreSQL 10

Step 3: Initialize the database.

Step 4: Open /var/lib/pgsql/data/pg_hba.conf file to change the authentication to md5.

Find the following lines at the bottom of the file and change peer to trust and idnet to md5

Once changed, it should look like the following.

Step 5: Start and enable PostgreSQL.

Step 6: You can verify the installation using the following version select query.

Setup Sonar User and Database

We need to have a sonar user and database for the sonar application.

Step 1: Change the default password of the Postgres user. All Postgres commands have to be executed from this user.

Step 2: Login as postgres user with the new password.

Step 3: Login to the PostgreSQL CLI.

Step 4: Create a sonarqubedb database.

Step 5: Create the sonarqube DB user with a strongly encrypted password. Replace your-strong-password with a strong password.

Step 6: Next, grant all privileges to sonrqube user on sonarqubedb.

Step 7: Exit the psql prompt using the following command.

Step 6: Switch to your sudo user using the exit command.

Setup Sonarqube Web Server

Step 1: Download the latest sonarqube installation file to /opt folder. You can get the latest download link from here. http://www.sonarqube.org/downloads/

2. Unzip sonarqube source files and rename the folder.

4. Open /opt/sonarqube/conf/sonar.properties file.

Uncomment and edit the parameters as shown below. Change the password accordingly. You will find jdbc parameter under PostgreSQL section.

By default, sonar will run on 9000. If you want on port 80 or any other port, change the following parameters for accessing the web console on that specific port.

If you want to access sonarqube some path like http://url:/sonar, change the following parameter.

Add Sonar User and Privileges

Create a user named sonar and make it the owner of the /opt/sonarqube directory.

Start Sonarqube Service

To start sonar service, you need to use the script in sonarqube bin directory.

Step 1: Login as sonar user

Step 2: Navigate to the start script directory.

Step 3: Start the sonarqube service.

Now, you should be able to access sonarqube on the browser on port 9000

Step 4: Check the application status. If it is in running state, you can access the sonarqube dashboard using the DNS name or Ip address of your server.

Setting up Sonarqube as a service

Step 1: Create a file /etc/systemd/system/sonarqube.service

Step 2: Copy the following content on to the file.

Step 3: Start and enable sonarqube

Step 4: Check the sonarqube status to ensure it is running as expected.

Troubleshooting Sonarqube

All the logs of sonarqube are present in the /opt/sonarqube/logs directory.

You can find the following log files.

Using tail command you can check the latest logs. For example,

For sonarqube support, visit this link

The post Install and configure Sonarqube on Linux (RHEL/Centos/ec2) appeared first on Tech Chronicles.

Step 1: Install Docker

Download Docker here if you’re not running it already, & install it. Docker containers are simply the best way to test out new tools with minimum fuss, in my opinion.

Step 2: Install SonarQube Community and Start It Up

You can do this by running the following 2 commands:

docker pull sonarqube 

docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube

Now, you can browse to http://localhost:9000, and you’ll be looking at the SonarQube Web GUI.

Easy, right?

Login with: admin/admin. Note the warning in red. This Docker image relies on an embedded H2 database that won’t handle a production environment. If you want to run a more production-like container, and you understand how docker-compose works, then you can find a recipe for adding PostgreSQL as the datastore here.

When you load the SonarQube webpage, you’ll be presented with a tutorial screen. Go ahead and generate a token. I named mine, “my-stinky-php-files.” Very original. Copy this token to your clipboard. We’ll use it later.

Most everyone uses SonarQube to analyze Java files. That’s too easy. For the tutorial, let’s choose a different language. Choose “Other.” Pick your OS. In my case, I’m running Debian Stretch, so I’ll choose, “Linux.” My unique project key will be “my-stinky-php-files.” I happen to have too many of these. Since we are not running this instance in a pipeline, and since we’ll be scanning some PHP code, we will download the CLI scanner. Unzip this into the folder: /opt/sonar-scanner-3.1.0.1141-linux.

You can check out the plugins while you are downloading the required companion scanner software. Note that you may see references to SonarQube Runner. Runner is simply the old name for Scanner.

From this point on we will be working in a Linux environment. Scanners are available for 64-bit versions of Windows, MacOS, Linux, and Any*. Moreover, you can choose to download & install a number of SonarQube scanners depending upon which language(s) you want to analyze or how you want to launch your scanner instances. These include scanners for MSBuild, Maven, Gradle, Ant, and Jenkins.

Now, change to your sonar-scanner/conf directory. For me the path is, “/opt/sonar-scanner-3.1.0.1141-linux/conf”. There is not much to configure. Unless you’ve changed the listening Docker ports you only have to delete the # sign at the start of the sonar.host.url line.

 #----- Default SonarQube server

#sonar.host.://localhost:9000

Next, add the Sonar Scanner /bin directory to your path:

 export \ PATH=$PATH:/opt/sonar-scanner-3.1.0.1141-linux/bin

If you want to add this PATH permanently, then make the change in your ~/.profile file. If you don’t do this, you will run into problems later – problems, in the sense that shell will not be able to locate sonar-scanner. You can verify that everything has gone right to this point by opening a new shell (or by sourcing your .profile if you chose that route) and executing the command sonar-scanner -h (on Windows the command is  sonar-scanner.bat -h). You will see some usage options.

One last thing to note when running the community edition of SonarQube. As far as I know, there is no way to generate reports as PDF’s or XML. You have to pay for that functionality.

Step 3: Let’s Start Scanning

Let’s see how ugly** my code really is.

When you use SonarQube, sadly you just can’t push a button and send it off to happily scan whatever software you’re evaluating. You have to do a bit of command-line work to get things moving. Fortunately, SonarQube provides you with a default scanning framework that will get you started. However, for most your particular projects you will likely tweak this framework to fit the project. For example, you may want to enter other directories, point to a particular set of Java binaries, etc.

In the case of this tutorial, we’ll go with the simple code that Sonar provides for us.

/opt/sonar-scanner/bin/sonar-scanner \

  -Dsonar.projectKey= my-stinky-php-files \

  -Dsonar.sources=. \

  -Dsonar.host.://localhost:9000 \

  -Dsonar.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Let’s break this command down.

First, for the Linux-challenged out there, the “\” (space-backslash) command indicates that the command continues over several lines.

 /opt/sonar-scanner/bin/sonar-scanner \  initiates the scanning process (If this isn’t in your $PATH, you’ll get an error stating that the file cannot be found)

 -Dsonar.-stinky-php-files  is a token that describes the set of file(s) that we are scanning. This name must be unique in a given SonarQube instance

 -Dsonar.sources=. \  is the location on disk of the files we will scan. If you’re not scanning from the folder that contains your files, provide an absolute path to that location. Replace “\” by “/” on Windows.

 -Dsonar.host.://localhost:9000 \  is the URI and port of our SonarQube web GUI

 -Dsonar.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  is the token we generated earlier that uniquely identifies you. This is the point that may befuddle some users when they start running regular scans.

If you intend to run a scan on a different project, or if you’ve had to reload your SonarQube docker instance, or if you’ve simply forgotten your token, go to the web GUI: Click on the administration tab. From there, click on the security drop-down box, and choose Users. If this is your first installation, then you’ll see the Administrator user. To the right of the Groups legend, you’ll see a Token legend. Click on this to generate a new token.

Now, let’s change to the directory that contains the files we want to scan and run the command above. Note, neither your project key nor token will be the same as mine.

Step 4: Now for the Pretty Stuff

If you’ve followed along so far, you’ll see some text run past, and, depending upon the number of files that you scan, it will take a few seconds to a few minutes to complete the scan. If, for some reason you can’t get to the Web GUI, check that the SonarQube container is running by typing:  docker ps .

You should see a response similar to that below. If you don’t then you’ll need to restart your container.

CONTAINER ID     IMAGE   COMMAND    CREATED   STATUS    PORTS            NAMES

576c9e4cb65d sonarqube " ./bin/run.sh" 10 hours ago Up 10 hours 0.0.0.0:9000->9000/tcp, 0.0.0.0:9092->9092/tcp sonarqube

When you see “ANALYSIS SUCCESSFUL,” you can head back over to the web GUI.

This is the main SonarQube results screen. In this case, I’ve run analyses on two different batches of code—some Java/XML, and some PHP/JavaScript. Since the code is proprietary, I’ve redacted the names in this and the following screenshots. There’s not a lot of detail on this home screen, so let’s take a look at some other screens that show more actionable details.

The code overview visualization. The closer a bubble’s color is to red, the more severe the worst bugs are. Bubble size indicates bug volume, and each bubble’s vertical position reflects the estimated time to address the bugs. Small green bubbles on the bottom edge are best. Hmmmm… Not looking good for this code.

This diagram shows a high-level view of SonarSource’s definition of “maintainability.” Currently, SonarQube measures nine major metrics. The definitions for those metrics can be found here.

The size and color of the bubbles are a reflection of the code smells’ long-term risks. The closer a bubble’s color is to red, the higher the ratio of technical debt is. Bubble size indicates code smell volume, and each bubble’s vertical position reflects the estimated time to address the code smells. Small green bubbles on the bottom edge are best. This diagram explains why the adjective “stinky” is appropriate for this code.

This “Reliability Overview” is a major quality gate metric. It is a general measure of security, and also whether the measured code actually works as the developer intends it to.

SonarSource defines a quality gate as a means to enforce a quality policy in your coding efforts.

It’s there to answer one question: can I deliver my project to production today or not?

SonarSource defines a default quality gate, the Sonar_way. Sonar_way is provided by SonarSource, is activated by default, and represents their view of the best way to implement code quality thresholds. The Sonar_way is a good starting point for determining metrics, but in the real world, it just makes sense to define this depending upon the project, and your organization’s risk appetite.

Step 5: Conclusion

This introduction is just that. There are other ways to run SonarQube both with and without Docker. There are so many ways to customize each particular scan that, really, the only solution is to RTFM. Hopefully, this introduction will get you going.  It will allow you to scan some code with SonarQube and visualize the results. Once you get to that point, you will be in a position to drill into the granularity of the SonarQube findings and to determine how best to work these findings into your current development workflows.

The post SonarQube Scanning in 15 Minutes appeared first on Tech Chronicles.