Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I recommend Renovate over any other dependency update tools

jvt.me

Post reply on HN
Print view View original

11–20 of 76 posts

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

#11

Post by k8sToGo »

vlovich123 wrote: post #7

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

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.

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

#12

Post by depr »

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

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

#13

Post by ozarker »

k8sToGo wrote: post #11
vlovich123 wrote: post #7

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

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?

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

#15

Post by jamietanna »

keybored wrote: post #14

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

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

#16

Post by pavel_lishin »

vlovich123 wrote: post #8
pavel_lishin wrote: post #6

Earlier quoted context omitted.

Across how many repos? My team owns a dozen.

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.

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

#17

Post by vlovich123 »

pavel_lishin wrote: post #16
vlovich123 wrote: post #8

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…

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.

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

#19

Post by 8organicbits »

gbrindisi wrote: post #5

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

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

#20

Post by dimitrios1 »

8organicbits wrote: post #19
gbrindisi wrote: post #5

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…

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