What's going on with Dependabot?
We're moving away from it and I'm not sure why it started to suck.
I loved Dependabot. I’ve used it since Grey Baker started it in 2017. I’ve seen it grow from a one-person shop to being acquired by GitHub in 2019. It’s been a fantastic tool that created more than 5,000 pull requests on Mergify repositories. I remember the excitement of finally having a tool that would bring all the new fancy features and bug fixes of my dependencies to my project in a snap.
Dependabot allowed us to fix a lot of security updates introduced by dependencies, and to be aware of anything new being released in the libraries we use.
But today, we kicked Dependabot out. Dependabot let us down.
Security You Said?
The move to acquire Dependabot from GitHub was smart. It was one of the key features that started their security roadmap with the acquisition of Semmle and their CodeQL engine the same year. GitHub has become all about security over the last few years, which makes sense considering the cybersecurity segment's hyper-growth over the last and upcoming years.
However, as Dependabot matured under GitHub, cracks started to show in what was once a flawless experience. The tool that was supposed to streamline security and updates became a source of frustration.
It has major design flaws that GitHub does not seem to care about.
First, Dependabot can fail silently. That happened to us multiple times a year when Dependabot would just stop working and create pull requests to update our packages. You’d think that debugging such an issue would be possible by going into the Dependabot tab of your repository, but no. The log for this is actually hidden in Insight → Dependency graph → Dependabot. A strange and unintuitive location for such crucial information.
Once you find your log, you can then read it and debug it yourself.
That’s a major problem because there’s nothing warning you that Dependabot is broken. We are used to updating our packages regularly, so we’d know, but there’s nothing preventing your dependencies and security updates from getting stale for months without you noticing. Terrible experience.
Always Lagging Behind
We’re a Python shop. We leverage poetry to manage our dependencies, and we use the latest Python version in our containers.
As a Python shop, staying on the latest version helps us ensure security, performance, and compatibility. So we update it as soon as we can, usually a few days after it’s released.
And then Dependabot is broken.
And you have to wait weeks for GitHub to fix the problem.
The last few times, we had to update ourselves Dependabot itself, as shown here or even here. We’re basically doing GitHub’s job for free, maintaining the Dependabot database ourselves for all their customers.
We contacted GitHub support about this already, and they did not care at all. Their laconic answer was, “Wait for it to be updated.”
Sure, thank you. We’re the ones doing the updates.
I get it—maybe Fortune 500 companies don’t care about the latest Python micro releases. But for startups like ours? It’s a big deal.
So today, we got rid of Dependabot and replaced it with Renovate. It seems better maintained and supports a larger package ecosystem than Dependabot. So far, it has simplified our workflow and is not broken on a simple Python micro update. 🤞
We’re also adding support for Renovate in Mergify Merge Protections, as we have done for Dependabot in the past. That will ensure you can write advanced rules for automatically merging your dependency update. 🦾 Let me know if you’re interested in trying it out!