Getting started with SonarQube (java, maven and docker 🐬)

How do we know if the code we write is good enough? Error free? Not vulnerable? Not smelly?

There are some tools that can show you that, and today I’m writing about SonarQube.

But, since I like the approach with minimum steps required, I’ll write just as much as I think it’s necessary for the beginning.

I’ll even set it up with Docker image. In case you’re not familiar with it, you may want to check Introduction To Docker: A Beginner’s Guide that I wrote.

SonarQube as a Docker image

Let’s keep it simple, we’ll run a SonarQube container, and after we are done playing with that, we can wipe it off from our system like it never existed. No external installations or things like that.

Step 1. Find the Community Edition Docker image on Docker Hub

docker pull sonarqube:8.5.1-community

Where did I get this? There’s a docker pull command on the SonarQube download page, ready to be copied. Check it out, newer versions may be available.

OK, image is there, now what? Like with every docker image, check the documentation on Docker Hub, here in our case.

You might want to read everything there, but I already did that for you. There will be a link that points to this piece of documentation

Step 2. Start the server by running:

docker run -d --name sonarqube -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -p 9000:9000 sonarqube:8.5.1-community

For now, I don’t know what this SONAR_ES_BOOTSTRAP_CHECKS_DISABLE flag is, but it's not important to understand for now. Obviously, you have to put it, since it's in bare minimum quick start documentation. And, you always can use a Google to check it on your own. I did a brief check and saw that SonarQube use ElasticSearch underneath, and this flag prevents some checks that we don't care about at the moment. We want to see SonarQube up and running.

Setting up SonarQube project

Log in to http://localhost:9000 with System Administrator credentials (login=admin, password=admin). If you can’t open the page immediately, wait a bit, don’t panic. If you keep refreshing like I did, you’ll see this at some point.

While logging in, you may notice this warning:

Embedded database should be used for evaluation purposes only

The embedded database will not scale, it will not support upgrading to newer versions of SonarQube, and there is no support for migrating your data out of it into a different database engine.

That’s totally fine for now. We could set up an external DB or map the storage volume, but for the purpose of quick start we’ll stick with the embedded DB. Definitely not recommended for production projects.

Click on that Create new project and put some names there

The next step is to generate a project token, which will be used for identification. Bear in mind that SonarQube will have access to your code (and have a copy for analysis purposes), so it’s important that you protect it. Again, important in production. This is a quick showcase, so you don’t have to worry too much about keeping those tokens, let’s just make it work.

To continue setting up the project, select Java and then select Maven as a build tool. This will generate for you the command that you need to execute in your project directory.

mvn sonar:sonar \
  -Dsonar.projectKey=demo-sonarqube \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=YOUR-TOKEN-HERE

Copy

Wait for the BUILD SUCCESS message from Maven and go to http://localhost:9000 again. Even better, you can click on the link in the maven log.

ANALYSIS SUCCESSFUL, you can browse http://localhost:9000/dashboard?id=demo-sonarqube

Project overview

You should see something like this. So let’s just take a brief overview of what you can see here:

• Quality gate status: Passed. You can set certain rules for quality gate and based on them, you’ll get a boolean, passed or not. Rule can be for example Test coverage 80%
• New Code / Overall Code: In the Overall, you can get all the reports within the project code base. In New Code, you can see the diff after running a second analysis of the same branch. So you can see only the analysis of your latest changes.
• Main reporting: Bugs, Vulnerabilities, Security issues, Code smells and technical debts. All with links included so you can dive in. Technical debt is measured by some average assumptions made by SonarQube, and it can give you the feeling how much time will you spent on solving these things.
• Coverage: I do have 3 unit tests, and SonarQube detects them, which is nice. However, I remember there has to be some SonarQube plugins activated (or configured) so it can detect line coverage. As you can see, it’s 0.0% at the moment, which I know it’s not correct.
• Duplication: This section can find and show how much duplicated code do you have in terms of line and percentage of your total code base.

Conclusion

SonarQube is a static code analysis tool. It will check your code against certain rules to see if there are some bugs, security issues, pitfalls etc.

You should use it since it gives you a lot of explanation of why and how you can improve your code. Of course, you don’t have to obey 100%, but at least consider making changes to your code.

You can set it up really simple with Maven, and especially if you install it as a Docker image.

The scope for this blog post is to show you the basics of SonarQube analysis. I plan to write a bit more on this topic later.

Rifkhan JM