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 Docker Images - Intro for beginners 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
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 1. Find the Community Edition Docker image on Docker Hub (we did this already)
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 wan't 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 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
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.
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=hashnode-blog-showcase \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=YOUR-TOKEN-HERE
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=hashnode-blog-showcase
Project overview
You should see something like this. So let's just take a brief overview 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.
Diving in, how can SonarQube help us?
OK, we see that there is one bug and 11 code smells on this project. How can we proceed? Well, the general rule of thumb is to start with Bugs, Vulnerabilities and Security issues.
What I like about SonarQube is that they report on what, where and how parts. Let's chase that bug. If I click on the link in the Bugs part, it will show me the details.
I can even navigate to the code and it will show me exactly where it is.
What I also like, is that SonarQube is giving you Severity overview, and you can see it's Major severity. There are two levels above Critical and Blocker. Pay attention to these.
The next cool thing I like about it is that you have all the description why you should change something. You probably saw that Why is this an issue? link. You'll often learn a thing or two from there. They also provide both compliant and non-compliant solutions. I'll show it in the next screenshot.
See? A very detailed overview. And you know what to do after reading it. Let's check the other issues we have so you can have a better picture how it looks like.
Your mileage may vary. If you have bigger project, you'll have more diverse issues. But, you get a nice foundation to continue from here.
Conclusion
SonarQube is 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 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.
Top comments (0)