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-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.
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
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
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..
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
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!