I use it at work and it’s fantastic.

It is, but at some point several dependencies might not be updated successfully for whatever reason, and I would like Renovate to retry to PRs or just close them in favour of running other dependency updates and then trying again.

Hm, we have it setup to do all dependency updates on the same branch/MR. We’ve had broken builds but it’s typically because of a breaking api change in a dep. We’ve never really had issues but we’ve only used it for node/golang that has pretty good dependency management systems.

Sadly randomly stopped working for me in Azure DevOps. It was good though.

So, I picked up a pretty easy process I've used for the last 10 years (at decade old small company with plenty of legacy code, Microsoft, & now a startup using go/rust/js)

Every Monday I update dependencies. Review breaking changes, get to know what CVEs are out there, glance over changelogs

It takes less than an hour a week. It keeps me up to date on our dependencies

Across how many repos? My team owns a dozen.

Monorepos definitely make it easier. There's a use for dependency bots, especially when collected into one PR so that it can be treated like a newsletter. Was wanting to point out that good habits can go far, but if you're hitting limits then automation is a boon

Ideally if there's multiple repos maintenance can be divided amongst those repo's owners, & once you've divided work between multiple people it becomes more valuable to have a tool help maintain process. These tools need buy in, I've found sometimes they'll go ignored & then the list of PRs becomes mixed up with random dependency PRs

Renovate creates an issue which lists the status of all dependencies in the repository, which it keeps updated. It then creates PRs for each dependency update, which can then have CI run individually to give an indication of any issues with the update.

It's downright excellent.

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 literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. But it was never particularly urgent.

Yup. Those “no longer actively developed” services should probably be rethought. Your carrying too much dead weight for the team size if updating the dependencies is “too much”. You’re just papering over the issue if you’re relying on automated tools to do basic book keeping for you.

>> they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host.

Make that step 4 or 5.

Mono repo them first! Yes you will have to build some tooling to do this but it gives you a way to test the concept. The moment that you have to change 2 of them with any degree of coordination you will get a 10x pay back.

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.

With Dependabot this takes me less than 10 min a week across 20 repos. Because we have lots of integration tests, we automerge patch updates automatically.

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've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation.

A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again.

[1] https://github.com/ralexander-phi/license_approval

GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.

It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.

These are proplems github customers have.

“Uncover” meaning “believe the same stuff that I believe, based on 20 year old tech history that everyone knows already”. There’s no secret here.

Would you like to spell them out? It's not exactly clear if you're thinking of the same ideas as other people, a conspiracy to take over the world, or something in between.

Why?

Just like with AWS SaaS offerings: All they need to do is have something basic, satisfying 80% customers, requiring little maintenance on their end.

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.

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.

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

I think it would be possible to fix it properly and without security risk by allowing pipeline authors to allowlist dependabot and/or specific forks for accessing secrets.

Cloudflare adopted Renovate when I worked there. Not sure if it was the config wasn’t good (we did try to wrangle with it a bit by customizing), but I found it to be a lot more pain that it was worth. PRs that wouldn’t build would be opened, trivial dependency updates that weren’t worth the PR time would be proposed, etc.

There’s also the security aspect of supply chain attacks of “button press” updates.

I think having reports sent to repo owners that they can review with the team on a periodic basis instead of click-through maintenance might be a better model but I also understand the desire for mindless automation of what seems like a chore.

I automated renovate PR into its own branch. Then twice a month I automatically create a PR through GitHub actions for me to review all changes at once.

I also added a cooldown period that Renovate should only add updates that are out for at least 14 days.

This sounds awesome can you share any details on how you got this to work?

I have a branch lock on dev and main so that you can only merge through PR. So I created a branch from dev called "renovate_updates". In the renovate config I set the baseBranch config parameter to this branch. I also enabled automerge and minimumReleaseAge.

On GitHub I created two actions:

1. It gets triggered on the 14th and the 1st of a month and creates a PR from renovate_updates to dev and assigns it to me. I use an action to identify as a github app that I have given the rights to in the repo. Within the github action you can use gh cli.

2. Everytime there is a merge to the dev branch the action gets trigerred and does a rebase of dev of that "renovate_updates" branch.

The nice thing about this is that Renovate creates an Issue in your repo and you can still force versions if you need them earlier.

What strategy do you use for conflicts during the rebase of renovate_updates? (which most of the time would occur because you eagerly updated something on dev)?

That’s a good point. My repo doesn’t change that often. But for me the source of truth is always dev.

We also had a similar setup at Algolia, renovate push to one branch (`baseBranch` properties) and you only review once a week or month. Created a GitHub actions to create the base branch with a cron: https://github.com/bodinsamuel/renovate-automatic-branch

So you have nothing to do except a big review once in a while.

> PRs that wouldn’t build would be opened

Isn't that exactly what you want from the dependency update system? If some dependency bump breaks the build, why wouldn't you want to know about it? And if not, how would this system know that the PR will fail before opening it? I'm not sure I get what behaviour you expect.

Renovate is still rough. My team has some repos that Renovate inexplicably doesn't vendor Go dependencies on, even though it works just fine with other repos with the same config.

Dependency updating and API version updating seem like great use cases for AI agents.

“AI, update this file from API V1 to API V2”

How about no.

Why not? It's a task that is not deterministically automatable, but has similar enough problems (changing method signatures, etc) that make it suitable for AI to learn from past examples and then apply to your codebase. And these are typically also accompanied by changelogs that can get injected into the prompt, etc.

I'm not some sort of AI fanboy. This just seems like a pretty decent use case.

When I tried it with Elixir around a year ago, it was pretty bad. Issues seemed to be caused by the fact that it parses the lockfile format, which is in Elixir, with Javascript. Dependabot doesn't have issues that (can) stem from that because it parses with Elixir code (so it doesn't have to reinvent reading Elixir maps).

Why does it seem to these tools have converged on the bot-makes-PR implementation? Why not a tool that bumps dependencies and let’s you propose yourself? I can’t use one of these tools because the integration is GitHub-only.

Renovate isn't special with how it authenticates - you can run it as your own user ie https://github.com/jamietanna/oapi-codegen/pull/12 and Renovate runs against GitLab, Bitbucket and I believe other platforms too

>> Why not a tool that bumps dependencies and let’s you propose yourself?

SO it opens an issue and gives you a patch file... Or emails it to you?

> Why does it seem to these tools have converged on the bot-makes-PR implementation?

Because git and the PR is the common choke point that every one knows and loves. A lot of dev's look down on "patches"... there are tons of people who happily use linux who think that all kernel devs are stupid cause of bugzila/patches and email could not possibly work.

Patch files? Normal tools change files. If I `sed -i` in my project I just change the files in my project. Then I (separately) can add and commit them. Same for (for example) linting tools. This bot-PR workflow is outside of that normal.

A PR is easy to automate, hook into, an preserves ownership of the commit.

Yes it bypasses YOUR workflow, but a PR works for everyone who uses GitHub.

If you want something else that works for everyone who uses GitHub it's an issue, or an email with a patch file. Why a patch file. DO you want to own the change the bot suggested? There are a lot of orgs where the ownership matters more than the linting.

You could just make the change yourself, sure, and then run it through your normal workflow... then your the author and commuter of the change...

I stepped into the wrong workflow synagogue it seems.

You mean on some individual person's laptop when that person remembers to run it?

Like most things.

But the whole point is not to have to do that. What you're asking for is basically just `npm upgrade` or `cargo upgrade` or whatever? The point of Renovate, Dependabot etc. is exactly the automated/scheduled running of those package manager updates.

Sigh. The answer to why they are this way is that it’s the whole point that they are this way.

Well yes? You're complaining that a motorbike has an engine when you're perfectly capable of and would rather power it with your own two legs.

What a great comparison.

If you had to submit the PR yourself, you’d have to remember to do it in the first place (and take the time to do it). Bumping a bunch of patch version numbers has never been the hard part and isn’t really what these tools solve. Their purpose is to reduce the effort involved to an absolute minimum so there are no excuses to fall behind on updates. Some of these tools, like Renovate, even have the ability to automatically merge the PR if the tests pass, meaning there’s zero human involvement.

If you had to submit the PR yourself, then these tools would be no different than an automated Jira ticket that’s created once per sprint.

(The actual hard part of all this is having good, meaningful, automated tests, but that can’t be solved by a bot.)

> If you had to submit the PR yourself, you’d have to remember to do it in the first place (and take the time to do it). Bumping a bunch of patch version numbers has never been the hard part and isn’t really what these tools solve. Their purpose is to reduce the effort involved to an absolute minimum so there are no excuses to fall behind on updates. Some of these tools, like Renovate, even have the ability to automatically merge the PR if the tests pass, meaning there’s zero human involvement.

I’ve seen a fair number of open “dependabot” PRs just lying around.

Renovate lets you run it locally as a oneshot Docker container (similar to a binary) with a personal access token, creating the PRs under your name.

Here's an example (made this repo to test a Renovate issue against): https://github.com/sunshowers/renovate-test-2

Thread a few months ago ~about a risk associated with getting habituated to automatic dependency-update PRs and looking at them less critically:

https://news.ycombinator.com/item?id=37680443

There's a risk to wearing your seatbelt and driving off a bridge into water as well.

Something to be aware of, but not a reason to ditch the belt.

In our projects 80% of renovate updates are broken PR-s. In theory it should save work, but it just generates more.

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.

If you don’t want to update dependencies frequently, then you should probably stop using (or reconfigure) the tool whose primary purpose is to help you update dependencies more frequently ;)

Well, I can't not use it since it's a company wide policy, but I agree with you.

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

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, and do the upgrade safely (disclosure: my startup Infield is in this space).

At my company, I feel just the opposite. Our frontend JS projects are lacking in enough unit, integration, and e2e that most of those devs are scared to touch any dependencies.

Where on our backends, we have such high code coverage, quality integration tests, the backend devs are never nervous about updating dependencies.

EDIT: I will also say, we are purely microservices so that does help in this regard.

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

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.

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.

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

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

I think it was in that repo discussions, but about IIRC Sphinx (whose plugins obviously depend on a specific version).

I imagine any plugin ecosystem of dependent packages would have the same issue.

> Author insists this is a problem with all package managers, that it's impossible to write a tool that doesn't behave like this

Is the author wrong? Dependabot functions the exact same way. How would you even go about solving this?

Started using renovate to update a few internal dependencies.

A few years later more than 30 projects using it and almost all of that growth happened naturally: https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot

We operate on a fork (5 commits or so) which contains some hacks to support a forked workflow on GitLab and some minor adjustments for that workflow. Really need to upstream some of it: https://gitlab.com/gitlab-org/frontend/renovate-fork/-/merge...

The author was always super kind, responsive and accommodating.