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
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
dependency update pull requests
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.