Live data from Hacker News

Why I recommend Renovate over any other dependency update tools

jvt.me

21–30 of 76 posts

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

#21

Earlier quoted context omitted.

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.

These are proplems github customers have.

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

#22

Earlier quoted context omitted.

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.

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

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

#24
post #13
post #11

Earlier quoted context omitted.

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.

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

#26

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

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

#27

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

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.

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

#28

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.

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

#29

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…

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

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

#30
post #24
post #13

Earlier quoted context omitted.

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

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)?
Post reply on HN