Dependabot... but for CircleCI

At BESTSELLER we are heavy users of our CI/CD tool CircleCI. Like many other modern CI/CD tools, it consists of a simple YAML file where you tell it what to run whenever it detects a change to a Git branch. Easy, and who doesn't love that? It does however mean that we have a YAML file in each Git repository. Each YAML file specifies which containers, images and orbs CircleCI uses when testing, building and deploying our software. Can you feel the headache building? We suddenly have hundreds of YAML files with individual versions.

In this post, I will cover how we at BESTSELLER keep our CI configurations updated and how you will be able to do the same.

Dependabot

Dependencies is not a new problem or a problem specific to CI/CD configurations. In almost any language you specify which packages and which versions you are using in your software. Other people already made magical solutions that you can utilize for this. At BESTSELLER we use Dependabot. Simply put; Dependabot monitors your dependencies and creates a pull request whenever there is an update to a certain dependency. From there, it is up to you to get that pull request merged. But Dependabot does not support our CI configurations. To the keyboard!

Why

But why create your own you might ask. To be honest we would love to get these features into the original Dependabot, but as Dependabot recently got acquired by GitHub their situation has currently changed:

Currently the Dependabot team is at reduced capacity, because of this our response times on issues and contributions will be slower than we'd like. *

And as we are impatient engineers we decided to create our own dependabot-circleci, specifically for CircleCI and written in Go.

dependabot-circleci

Which dependencies can we monitor? and how does this work? We have tried to mimic the original Dependabot as much as possible, but let's have a look at the details.

An example configuration for CircleCI could look like this

 1version: 2.1
 2
 3executors:
 4  docker_image:
 5    docker:
 6      - image: docker:19.03-git
 7
 8orbs:
 9  secret-injector: bestsellerit/secret-injector@1.0.3
10
11jobs:
12  build:
13    executor: docker_image
14    steps:
15      - checkout
16      - setup_remote_docker
17      - attach_workspace:
18          at: /tmp
19      - run:
20          name: Build and push image
21          command: |
22            docker build
23            docker push            

Our two main dependencies is the docker image docker:19.03-git and the orb bestsellerit/secret-injector@1.0.3. Currently these are the two dependencies we can monitor and detect updates for. When an update is detected it will create a pull request in the Git repository, just like Dependabot. Below is an example of a pull request created by dependabot-circleci, and we can see that a newer version of the Terraform image has been detected.

All we have to do now is to merge the request! Simple! At least I think it is :)

How to

Honestly getting started is a bit tedious at the time of writing, as we have not published the GitHub app yet. You must clone our repository and configure the application in our own github organization/user. Don't worry, this will change.

The easy part is how to configure which repositories to monitor. You enable dependabot-circleci by checking a dependabot-circleci.yml configuration file in to your repository's .github directory. The configuration file could look something like

 1# example dependabot-circleci.yml file
 2assignees:
 3  - github_username # for a single user
 4  - org/team_name # for a whole team (nested teams is the same syntax org/team_name)
 5labels:
 6  - label1
 7  - label2
 8reviewers:
 9  - github_username # for a single user
10  - org/team_name # for a whole team (nested teams is the same syntax org/team_name)
11target-branch: main

As seen above, you have different options, so you can tailor the pull requests to your liking.

• Assignees to set on pull requests, as seen above, can be team as well as users.
• labels to set on pull requests, defaults to circleci and dependencies
• reviewers to set on pull requests, as with assignees you can chose both teams and users.
• target-branch. Branch to create pull requests against. You might want pull requests to hit your development branch? If not specified, it will use the repository's default branch.

If you make a configuration mistake, don't worry, a small GitHub check will run. This will catch unknown fields and types.

That's it! Prepare for incoming pull requests!

Final words

If you are using CircleCI, like us, I believe this is a brilliant addition to your toolbox. You won't end up in situation with year old dependencies and all you have to do is add a single file to your repository.

Next steps for the dependabot-circleci is to publish the application, and establish how we want to run the application, so you don't have to do that yourself. Beside the publication we would like more granular scheduling, so you can decide for each repo if it should be e.g. daily, weekly or monthly.

The dependabot-circleci is open source, and we are more than happy to recieve contributions and ideas.

About the author

Peter Brøndum

My name is Peter Brøndum, I work as a Tech Lead and Scrum Master in a platform engineering team at BESTSELLER. Our main priority is building a development highway, with paved roads, lights and signs, so our colleagues can deliver value even faster. Besides working at BESTSELLER, I — amongst other things, am automating my own home, and yes, that is, of course, running on Kubernetes as well.