Dependabot is the biggest source of PR spam for me as it's config is so simplistic, you can't easily make it group upgrades. So, when I see suddenly almost a hundred PRs created, I do the upgrade myself, push it, and then Dependabot closes the PR, but I love the hundreds of emails around this process, too.
You can now group PRs with Dependabot ( https://github.blog/2023-08-24-a-faster-way-to-manage-versio... ) although it's not quite as powerful as Renovate's functionality
Why I recommend Renovate over any other dependency update tools
51–60 of 76 posts
Re: Why I recommend Renovate over any other dependency update tools
#52I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.
Re: Why I recommend Renovate over any other dependency update tools
#53I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil.
I wonder if they fixed it since.
Re: Why I recommend Renovate over any other dependency update tools
#54Stopped using Renovate when I discovered that it will happily propose a PR update for completely incompatible and conflicting dependencies. It literally looks at the latest version of each dependency alone, without considering if this will make a conflict.
Author insists this is a problem with all package managers, that it's impossible to write a tool that doesn't behave like this, and that manually grouping dependencies or completely ignoring version updates until the next one is the only sensible approach.
This doesn't save me time.
Re: Why I recommend Renovate over any other dependency update tools
#55Earlier quoted context omitted.
Sounds like you might be understaffed.
It's microservice land! Most of those services are no longer in active development, and nearly all of them support a single actual product. In my opinion, we split them to aggressively at the start - expecting some of them to be used by other people in the company, as a service type of situation - but that never happened. I argued for combining several of them - they don't share any paths for API calls, so it could l…
95% of our changes are done by renovate. We rarely have to deal with breaking changes on anything backend related, though the frontend is a different story. But our frontends aren’t exactly “microservices” anyway, and they are always very much in active development.
I build a couple of services which collects a gazillion tonnes of solar inverter data from various plants over the world, and then does some fancy ML magic to figure out which solar cells need cleaning, and it has run for years with automated dependency updates with nothing breaking because of how it was build from the start.
I get that if your microservices are really just a bunch of tiny monoliths then it’s hell, but then you should probably prioritise your suggestion of merging it together somehow.
Re: Why I recommend Renovate over any other dependency update tools
#56Figuring out whether the upgrade is safe is a hard problem. I've found renovate most successful in frontend JS projects where you have a ton of dependencies all with new versions coming out all the time, most of which are non-breaking, and where the danger of a bad upgrade is not that large. For backend work or once you've gotten the easy stuff out of the way you really need to review the changelog, assess the risk,…
Re: Why I recommend Renovate over any other dependency update tools
#57I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added. Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen
Last time I tried (which is >2y ago, so things might have improved), dependabot seemed like an afterthought for GitHub. For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also appli…
Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).
Re: Why I recommend Renovate over any other dependency update tools
#58Ugh, no. Stopped using Renovate when I discovered that it will happily propose a PR update for completely incompatible and conflicting dependencies. It literally looks at the latest version of each dependency alone, without considering if this will make a conflict. Author insists this is a problem with all package managers, that it's impossible to write a tool that doesn't behave like this, and that manually grouping…
Re: Why I recommend Renovate over any other dependency update tools
#59Re: Why I recommend Renovate over any other dependency update tools
#60Earlier quoted context omitted.
But are they broken because of renovate? Or just the underlying dependency updates?
It's the dependency updates. It doesn't consider if the update makes sense or not. If it fixes vulnerabilities it must be updated, but just for the sake of updating, I don't see the point.
1. take on the additional risk of months or years of changes in between
2. beg or plead with (or throw money at) upstream to patch your old version
3. attempt to patch it yourself, potentially introducing new issues because you're not the domain expert