Enabling Dependabot

I have a small pile of old Ruby based Puppet modules and extensions that I don’t use anymore but have had some adoption and so thanks to an over abundance of guilt I make the occasional attempt to ensure they are still working and kept vaguely up to date. With the GitHub acquisition of Dependabot, an automated dependency update service, I decided to enable it for a few repos and see how it fits my work flow.

I started off adding a single repo, the concisely named puppet-lint-concatenated_template_files-check, via the Dependabot WebUI. I picked ruby as the language and chose to have Dependabot check the dependencies once a day. And then waited. It took a few minutes and suddenly the deluge began. Did you know Rake had a major version of 13 now? I didn’t.

After adding a couple more repositories I waited a week or so and worked through the pull requests as they came in. You can see an example of one of the dependency update pull requests against my puppet-liquidtemplates function. I soon realised when using Dependabot you’ll live or die based on the tests you have. For example most of my modules have rspec tests, but don’t have functional ones implemented using something like test-kitchen, so while I’m quite confident accepting proposed updates to development dependency gems I’m a lot more cautious with the run time dependencies. If you have no tests you’ll soon be playing Russian roulette with each and every Dependabot PR you merge.

At this point I was comfortable enough with the workflow and the benefits it brought to attempt a wider role out. The main downside was the need to manually add a repo and its settings via the Dependabot website. I’m not a fan of this kind of indirect action at a distance so I looked into other ways to enable it for specific repos. After reading some of the docs I found the .dependabot/config.yml file and began a wider roll out.

version: 1
update_configs:
  - package_manager: "ruby:bundler"
    directory: "/"
    update_schedule: "weekly"
    default_assignees:
      - "deanwilson"
    default_reviewers:
    - "deanwilson"

Now I knew what kind of PR volume to expect I dropped the update schedule down and started to assign myself to the pull requests so I’d hopefully notice them arriving (while that has technically worked but I’ve not started reacting to them any faster). I’m a little undecided about continuing to roll Dependabot out to my repos. While I do appreciate the importance of keeping things up to date a lot of my code could at best be considered to be in maintenance mode and because of Dependabot I’ve done a large amount of archiving of repos. I’m also a little worried about how easy it is to confuse motion with progress. While we all love the little dopamine hit of reviewing and merging a pull request I’m not sure exactly how much impact merging another rubocop update is actually having. I can see why this raised level of interaction with GitHub is great from their angle, and it does bring security and maintenance benefits to many projects, I’m just not sure it’s a win for smaller projects like mine.

Still, it’s good for my GitHub activity stats I guess.