For people complaining that Dependabot is too noisy, it is easy to configure it to only open PRs for major versions.
I am a big fan of Dependabot, but maximizing its effective is highly dependent on the culture of the team/codebase.
Ask HN: How do you work with Dependabot?
41–46 of 46 posts
Re: Ask HN: How do you work with Dependabot?
#42My main gripe is that Dependabot can end up raising multiple PRs for the same dependency bump in the same repo (especially with Dockerfiles). I really wish I could tell it to do rollups e.g. `@dependabot rollup #1234 #1235 #1236` or something like that. To save having to do multiple rounds of merge PR, rebase next PR, wait for CI... I end up doing my own rollup PRs by merging the various Dependabot branches. At least…
Yes. 'Rollups' would also help the situation where multiple upgrades in combination will cause an issue. Ideally though, you'll be merging master into each automated pull request regardless. But rollups would save a bit of time.
Re: Ask HN: How do you work with Dependabot?
#43We don't use it on our Node app because it would be too noisy. Another noisy library was the AWS SDK for .NET. In that case, I actually use a wildcard version range `3.7.*` to always have the latest patch release and cut down on Dependabot noise.
We have it on for everything else (.NET/Nuget, Ruby, Docker, GitHub Actions, Git Submodule). It's great at keeping us up to date with little effort. For major (and some minor) releases, I'll read release notes to see if there's anything to watch out for.
It's especially useful for updating the git repo we use as a submodule in 5 other repos. Submodules were a source of frequent merge conflicts before as different developers updated it in their PRs. Now we pretty much don't think about it, and Dependabot keeps it up to date with our latest database models and shared libraries.
edit: We have it set to weekly for everything but the submodule, which is daily.
Re: Ask HN: How do you work with Dependabot?
#44Earlier quoted context omitted.
That would be a shallow reading, however. The last two major runtime issues wer actually one that broke the test runner and ignored a number of tests. And another runtime error was a Python Django specific sub dependency that broke the admin interface, which obviously, we don't explicitly test. On the other hand, very recently, we had to abort a release, because of an outdated dependency that Dependabot DID actually…
Most test runners have an option (or can be easily modified) to fail when 0 or less than X tests have been run. You should use it for situations like this.
But what if there's also a bug where that feature doesn't work :)
Re: Ask HN: How do you work with Dependabot?
#45Earlier quoted context omitted.
Most test runners have an option (or can be easily modified) to fail when 0 or less than X tests have been run. You should use it for situations like this.
But what if there's also a bug where that feature doesn't work :)
What if there's a bug where your CI ignores all steps? There's always some situation possible and we can go all the way to nasal demons. You have to accept the risk at some point.
Re: Ask HN: How do you work with Dependabot?
#46It would be really helpful if dependabot mentioned how much bigger my build size would be relative to the main branch.