Terraform provider for Code Climate is open-sourced

Here is a short release notice. At Babbel, we’ve been using Code Climate successfully for a while, but we were unhappy about the lack of the Terraform provider for it.

---

Why Code Climate?

The answer will be short: We care about the quality of the code we’re producing, because a clean code base is easier to maintain and evolve. This, in turn, means we can ship features faster which directly impacts our users. Code Climate helps us to automatically detect code smells, missing test coverage, and so on, right during the build process on our CI stage.

How we lived before

For us, configuring Code Climate is a pretty common task to do. We already have a few hundreds of repositories and we add new ones regularly. For most if not all, we decide to configure Code Climate checks. Unfortunately, this process was still not automated.

If you adopted Infrastructure as Code, you must be familiar with the following feeling: Most of your configuration for infrastructure and 3rd-party services is codified, but you end up with edge cases that either cannot be codified or you just didn’t have time for this. Dealing with those remaining services make you feel insecure, as manual configuration is more error-prone than Infrastructure as Code: Manual configuration is missing common best practices like pull request reviews and versioning for every change. So you start thinking, how may you improve the situation.

If there is a Terraform provider for this, you have no doubts and can simply go and use it. However, in a case like ours, you have a choice, and the low hanging fruit here is a simple bash script. It can be used, because the external data source type in Terraform allows you to use any executable, e.g., a bash script, to bring some data to the Terraform state. Getting the data, without being able to complete the whole REST actions cycle, was a good enough for us at the moment, so we wrote a script for ourselves and integrated it with the current Terraform code.

The bash script:

#!/bin/sh

set -e

curl \
  -H "Accept: application/vnd.api+json" \
  -H "Authorization: Token token=$1" \
  https://api.codeclimate.com/v1/repos?github_slug=$2 |
  jq '.data | .[0] | .attributes | .test_reporter_id | { "test_reporter_id": . }'

The way to integrate it:

data "external" "codeclimate-babbel-gem" {
  program = [
    "bin/cc_test_reporter_id.sh",
    "link-to-a-secret-from-aws_secretsmanager_secret_version",
    "${github_repository.babbel-gem.full_name}",
  ]
}

It gets a repository from Code Climate and extracts the test_reporter_id from there. Bash scripts are great for many purposes. However, in this case, we rather prefer a more “native” solution.

The current setup

So, this is what we’ve done:

We’ve created a Terraform plugin for Code Climate. It was not our first provider, you can also take a look at one that we built for Rollbar.

We still implemented just the data source (so, reading from Code Climate), but not a fully functioning resource. The reasons you can find in the section Limitations below.

Currently, the definition of Code Climate repository looks pretty much the usual Terraform way:

data "codeclimate_repository" "babbel-gem" {
  repository_slug = "${github_repository.babbel-gem.full_name}"
}

And this is better because we don’t need to maintain dependencies outside of Terraform, like jq for parsing of Code Climate response. If you have worked with Terraform and its HashiCorp Configuration Language (HCL) before, those three lines of code should feel familiar.

Limitations

However, we would like to not just describe the existing resources, but also to create new ones, using Terraform, as you’d always do. Having everything described in code is great, but what is best is to be able to manage these resources in code. And we’ve tried to add this functionality into the provider.

Unfortunately, it turned out, that Code Climate API misses some features, which are crucial for our use case if we wanted to automate it:

1. The repositories#create creates side effects on the GitHub side (webhook and SSH deploy key), which in result won’t be managed by Terraform and in case of a deletion of the repository on Code Climate side, we will still have to manually delete the GitHub part. Which means that it is pretty much error-prone.
2. Code Climate API doesn’t provide a way to manage users’ permissions. This means we have to manually grant access to the respective repository for the Engineering team after creating a repository in Code Climate using Terraform. Which is again a manual step.

These two facts make further development of the provider not that appealing from our side. Yet, once they’re improved, we might think to resume the development.

Conclusion

We still will be glad if Code Climate will take over the development because we’re affiliated neither with them nor with Terraform. However, it’s a great feeling when you’ve built something, that you can share. Also, it was important for us to get rid of yet another bash script using a dependency outside of Terraform (like jq), and the goal is achieved. If the future provider will be based on our foundation – we’re happy to help to get on board with the architecture, though the provider is pretty small anyway.

If you feel that you want to contribute – you know, it’s open, so feel free!

Thank you for reading.

Photo by Max Duzij on Unsplash