Terraform your CICD Toolchain : SonarQube
Table of Contents
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.
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 😉
☕ This blog is powered by a coffee-lover
If you enjoyed this post, or any other of this blog content, you can send your feedback by contacting me or also contributing with a virtual coffee.
Thank you ! 👍