Dependabot is used for keeping dependencies up to date. This bot checks your project for outdated dependencies and then creates a pull request with the updated libraries it finds.
Dependabot Script
Dependabot-core runs against all github projects by default, but this poses a problem for me as someone who hosts most of my open source projects on Gitlab. I wanted this tool to run against my projects so I stood up the bot to run on a cron schedule every Sunday.
Setup
Before jumping straigt into the deepend and running the CI script immedietly, I decided to dip my toe in the water by pulling the dependabot-core image off docker and work with using a good old fashioned docker run command with it.
I didn’t run into any issues until I hit the github read limit and realized they really have a tight grip on their API.
Below is the docker script I came up with to run dependabot on my compositional-enterprises/homstatic repo.
docker run -v "$(pwd):/home/dependabot/dependabot-script" -w /home/dependabot/dependabot-script -e GITLAB_ACCESS_TOKEN=$(cat /home/jack/gitlab_p
at.txt) -e PROJECT_PATH=compositional-enterprises/homstatic -e GITHUB_ACCESS_TOKEN=$(cat /home/jack/github_pat.txt) dependabot/dependabot-core bund^C exec ruby ./generic-update-scri
pt.rb
Walking through this is like any standard docker run command. Basically I am running the dependabot-script in a docker container to run against a gitlab project of mine. Really the onlything that stands out here is the GITLAB_ACCESS_TOKEN, the PROJECT_PATH and the GITHUB_ACCESS_TOKEN. These three are needed to access your gitlab repo, know which repo to check, and allow read access to multiple (5000 in an hour) github repos to check if dependencies have broken.
There isn’t too much that stands out with this as someone already wrote the script to do the leg work. All I needed to do was configure it for my specific project. Configuring Gitlab’s CI was harder, and by harder I mean I changed out a few variables and wiped a decent amount of the script out using the web IDE… shhhhh.. don’t tell anyone I used the web IDE to directly commit to master..
Gitlab CI
I have no idea what the maintainers of dependabot/dependabot-script were on (whether they smoked it or picked a version from the stone age; meant to be double play on words with the “were on”) when they created the gitlab-ci.example.yml, but I have never seen that gitlab-ci syntax in my life.
I basically took their cicd, wiped it except for the important part and wrote my own version. It looks something like this:
image: dependabot/dependabot-core
variables:
PACKAGE_MANAGER_SET: bundler
before_script:
- bundle install -j $(nproc) --path vendor
stages:
- build
Build:
stage: build
variables:
PACKAGE_MANAGER_SET: bundler
script:
- bundle exec ruby ./generic-update-script.rb
only:
- schedules
What is so special about this. For starters it only runs on ruby projects because I set PACKAGE_MANAGER_SET to only include bundler. I wanted to confirm this worked at all before going forward. This is just 1.0!
And again everything is pretty standard, but notice that the Build only runs on Schedules!
Within schedules, Gitlab makes it realll nice to create a schedule and then run the schedule with specific environment varialbes.
This allowed me to run dependabot against all 2 of my rails projects! Manual dependency check no more!