Terraform your CICD Toolchain : SonarQube

So, in the previous article we’ve Terraformed GitHub (that must hurt), so let’s continue with another tool commonly used in a CICD process : SonarQube.

For a brief introduction in case you don’t know this tool, SonarQube (or SonarCloud for its SaaS version) is an open-source software published under LGPL v3 made for Static Code Analysis having both free and paid Enterprise plans. Basically, SonarQube will analyse the source code, use a big set of rules associated to the language, and throw issues if it found bugs, regressions, security hotspots, duplicated code lines, code test coverage, or code smells. Code smells are more optimization or cleanup opportunity than actual bugs, for example : remove commented code, remove unused imported library, etc.

For the purpose of this article’s demonstration, I’ll use the Community Edition of SonarQube installed in a local Kubernetes instance (minikube).

My SonarQube instance is completely empty, all brand new. The only thing I’ve made was to generate a token for the admin user.

The Terraform provider

Unlike GitHub, there is no Partner Provider available at Terraform’s Registry, but two community-powered. I’ve choose the one made by Joel Damata because the other one didn’t received any commit since two years.

So let’s configure this. I’ve made a similar layout as GitHub with three files :

• main.tf : The main code of the terraform template
• vars.tf : My global variables definition
• provider.tf : The SonarQube provider setup

All files are available on GitHub.

Try the project

We’ll go in the same dance move as with GitHub, first init the project.

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of jdamata/sonarqube...
- Finding latest version of hashicorp/github...
- Installing jdamata/sonarqube v0.15.5...
- Installed jdamata/sonarqube v0.15.5 (self-signed, key ID 0F6D68D6CF9E3F5D)
- Installing hashicorp/github v5.12.0...
- Installed hashicorp/github v5.12.0 (signed by HashiCorp)

Then, plan, then apply.

$ terraform plan

$ terraform apply

I had a lot of issues with my SonarQube on Minikube, getting quickly unresponsive event with 8GB RAM and 4 CPU. But I’ve also noticed that Terraform was attacking the API quite fast and SonarQube could not follow especially because it’s an application that works a lot asynchronously. That’s why I’ve put a time_sleep instruction for the groups permissions settings.

So, let’s check what it did. We have the project, the teams, and the permissions. Great !

But the project is basically an empty shell : it’s not connected to the GitHub repository. Meaning we still have manual steps to do, that’s not our goal.

Enhance this

So, being able to create projects in SonarQube with Terraform is nice, but the goal of our idea is to save time and avoid doing all these steps in the tools. Even if Terraform can automate the action, it’s still two separate workflows. So, let’s try to create a full operational workflow that will create the code repository, and prepare the Sonarqube project for an application in the Poochi Corp Organization. That will be for the next article 😉