Live data from Hacker News

Why I recommend Renovate over any other dependency update tools

jvt.me

51–60 of 76 posts

Re: Why I recommend Renovate over any other dependency update tools

#51
post #35

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

As I said, it's not easy, and not everything is possible either. Monorepos are the biggest victim. I wrote a script that generates the Dependabot config and a GitHub action that updates it when my monorepo changes.

Re: Why I recommend Renovate over any other dependency update tools

#52

I 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

I just want to be able to browse the dependencies of my repo with a web UI. Show me a tree of dependencies in my repo, filter for ones that are outdated, expand them to show what would be in a dependabot PR (the keen description it generates that contains all the release info and links to changelogs and whatnot). Then let me open a PR (or tell dependabot to do so) with the click of a button, or ignore it with another.

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

#53

I 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 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

#54
Ugh, 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 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

#55

Earlier 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…

Why wouldn’t you just bundle your shared dependencies in libraries so you would only have to update them in one location anyway? We put all our shared utilities into service libraries which are injected into our microservices when they are build. Since the APIs they consume are build to be non-breaking on changes, any external packages that get updated will only need to have their breaking changes solved in one location.

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

#56

Figuring 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,…

You need to write tests against your libraries, not just your own code!

Re: Why I recommend Renovate over any other dependency update tools

#57
post #53

I 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…

Oh yes, https://github.com/dependabot/dependabot-core/issues/3253. I wouldn't go so far as saying it was locked because it was too uncivil, mostly just because "additional commentary wasn't adding value" ;)

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

#58
post #54

Ugh, 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…

This is significant. Where did you read this? I found:

https://github.com/renovatebot/renovate/discussions/26917

Re: Why I recommend Renovate over any other dependency update tools

#60

Earlier 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.

The main reason to update dependencies is that when emergencies do arise, you don't want to be in the situation where your only options are:

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

Post reply on HN