9 ms·

Why I recommend Renovate over any other dependency update tools

185 points by ingve 3y ago

tflinton 3y ago
I use it at work and it’s fantastic.
- sebazzz 3y ago
  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.
  - tflinton 3y ago
    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.
__s 3y ago
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
- pavel_lishin 3y ago
  Across how many repos? My team owns a dozen.
  - vlovich123 3y ago
    Sounds like you might be understaffed.
    - pavel_lishin 3y ago
      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.
      - vlovich123 3y ago
        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.
      - zer00eyz 3y ago
        >> 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.
      - devjab 3y ago
        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.
  - __s 3y ago
    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
    - occz 3y ago
      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.
- oweiler 3y ago
  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.
FvKdgxD 3y ago
Sadly randomly stopped working for me in Azure DevOps. It was good though.
gbrindisi 3y ago
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 https://github.com/github/evergreen
- 8organicbits 3y ago
  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 https://github.com/ralexander-phi/license_approval
  - dimitrios1 3y ago
    It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
    - bluGill 3y ago
      These are proplems github customers have.
    - cqqxo4zV46cp 3y ago
      “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.
    - viraptor 3y ago
      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.
vlovich123 3y ago
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.
- k8sToGo 3y ago
  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.
  - ozarker 3y ago
    This sounds awesome can you share any details on how you got this to work?
    - k8sToGo 3y ago
      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.
rco8786 3y ago
Dependency updating and API version updating seem like great use cases for AI agents. “AI, update this file from API V1 to API V2”
- HumanOstrich 3y ago
  How about no.
  - rco8786 3y ago
    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.
depr 3y ago
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).
keybored 3y ago
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.
- jamietanna 3y ago
  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 https://github.com/jamietanna/oapi-codegen/pull/12 and Renovate runs against GitLab, Bitbucket and I believe other platforms too
- zer00eyz 3y ago
  >> 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.
  - keybored 3y ago
    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.
    - partdavid 3y ago
      You mean on some individual person's laptop when that person remembers to run it?
      - keybored 3y ago
        Like most things.
abathur 3y ago
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 https://news.ycombinator.com/item?id=37680443
- Terretta 3y ago
  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.
tiborsaas 3y ago
In our projects 80% of renovate updates are broken PR-s. In theory it should save work, but it just generates more.
- nonethewiser 3y ago
  But are they broken because of renovate? Or just the underlying dependency updates?
  - tiborsaas 3y ago
    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.
    - noahtallen 3y ago
      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 ;)
      - tiborsaas 3y ago
        Well, I can't not use it since it's a company wide policy, but I agree with you.
    - sunshowers 3y ago
      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
aswihart 3y ago
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).
- jml78 3y ago
  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.
- esafak 3y ago
  You need to write tests against your libraries, not just your own code!
nikolay 3y ago
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.
- jamietanna 3y ago
  You can now group PRs with Dependabot (https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-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
  - nikolay 3y ago
    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.
misnome 3y ago
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.
- esafak 3y ago
  This is significant. Where did you read this? I found: https://github.com/renovatebot/renovate/discussions/26917 https://github.com/renovatebot/renovate/discussions/26917
  - misnome 3y ago
    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.
- graynk 3y ago
  > 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?
peter6996 3y ago
[flagged]
leipert 3y ago
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 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_requests/1/commits https://gitlab.com/gitlab-org/frontend/renovate-fork/-/merge... The author was always super kind, responsive and accommodating.

185 points by ingve 3y ago

tflinton 3y ago

I use it at work and it’s fantastic.

sebazzz 3y ago
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.
- tflinton 3y ago
  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.

__s 3y ago

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

pavel_lishin 3y ago
Across how many repos? My team owns a dozen.
- vlovich123 3y ago
  Sounds like you might be understaffed.
  - pavel_lishin 3y ago
    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.
    - vlovich123 3y ago
      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.
    - zer00eyz 3y ago
      >> 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.
    - devjab 3y ago
      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.
- __s 3y ago
  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
  - occz 3y ago
    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.
oweiler 3y ago
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.

FvKdgxD 3y ago

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

gbrindisi 3y ago

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 https://github.com/github/evergreen

8organicbits 3y ago
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 https://github.com/ralexander-phi/license_approval
- dimitrios1 3y ago
  It's not so dumbfounding when you uncover what Microsoft's real goals and aspirations are for Github.
  - bluGill 3y ago
    These are proplems github customers have.
  - cqqxo4zV46cp 3y ago
    “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.
  - viraptor 3y ago
    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.

vlovich123 3y ago

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.

k8sToGo 3y ago
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.
- ozarker 3y ago
  This sounds awesome can you share any details on how you got this to work?
  - k8sToGo 3y ago
    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.

rco8786 3y ago

Dependency updating and API version updating seem like great use cases for AI agents. “AI, update this file from API V1 to API V2”

HumanOstrich 3y ago
How about no.
- rco8786 3y ago
  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.

depr 3y ago

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

keybored 3y ago

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.

jamietanna 3y ago
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 https://github.com/jamietanna/oapi-codegen/pull/12 and Renovate runs against GitLab, Bitbucket and I believe other platforms too
zer00eyz 3y ago
>> 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.
- keybored 3y ago
  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.
  - partdavid 3y ago
    You mean on some individual person's laptop when that person remembers to run it?
    - keybored 3y ago
      Like most things.

abathur 3y ago

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 https://news.ycombinator.com/item?id=37680443

Terretta 3y ago
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.

tiborsaas 3y ago

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

nonethewiser 3y ago
But are they broken because of renovate? Or just the underlying dependency updates?
- tiborsaas 3y ago
  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.
  - noahtallen 3y ago
    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 ;)
    - tiborsaas 3y ago
      Well, I can't not use it since it's a company wide policy, but I agree with you.
  - sunshowers 3y ago
    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

aswihart 3y ago

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

jml78 3y ago
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.
esafak 3y ago
You need to write tests against your libraries, not just your own code!

nikolay 3y ago

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.

jamietanna 3y ago
You can now group PRs with Dependabot (https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-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
- nikolay 3y ago
  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.

misnome 3y ago

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.

esafak 3y ago
This is significant. Where did you read this? I found: https://github.com/renovatebot/renovate/discussions/26917 https://github.com/renovatebot/renovate/discussions/26917
- misnome 3y ago
  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.
graynk 3y ago
> 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?

peter6996 3y ago

[flagged]

leipert 3y ago

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 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_requests/1/commits https://gitlab.com/gitlab-org/frontend/renovate-fork/-/merge... The author was always super kind, responsive and accommodating.