[HN Gopher] Why I recommend Renovate over any other dependency u...
___________________________________________________________________
Why I recommend Renovate over any other dependency update tools
Author : ingve
Score : 140 points
Date : 2024-04-12 10:35 UTC (12 hours ago)
(HTM) web link (www.jvt.me)
(TXT) w3m dump (www.jvt.me)
| tflinton wrote:
| I use it at work and it's fantastic.
| sebazzz wrote:
| 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 wrote:
| 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.
| FvKdgxD wrote:
| Sadly randomly stopped working for me in Azure DevOps. It was
| good though.
| __s wrote:
| 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 wrote:
| Across how many repos? My team owns a dozen.
| vlovich123 wrote:
| Sounds like you might be understaffed.
| pavel_lishin wrote:
| 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 wrote:
| 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 wrote:
| >> 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.
| __s wrote:
| 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 wrote:
| 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.
| gbrindisi wrote:
| 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
| 8organicbits wrote:
| 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
| dimitrios1 wrote:
| It's not so dumbfounding when you uncover what Microsoft's
| real goals and aspirations are for Github.
| bluGill wrote:
| These are proplems github customers have.
| cqqxo4zV46cp wrote:
| "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.
| jacques_chester wrote:
| 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.
| playingalong wrote:
| 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.
| chuckadams wrote:
| 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.
| Tainnor wrote:
| 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.
| vlovich123 wrote:
| 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 wrote:
| 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 wrote:
| This sounds awesome can you share any details on how you got
| this to work?
| k8sToGo wrote:
| 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.
| riquito wrote:
| 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)?
| k8sToGo wrote:
| That's a good point. My repo doesn't change that often.
| But for me the source of truth is always dev.
| h1fra wrote:
| 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.
| rco8786 wrote:
| 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 wrote:
| How about no.
| depr wrote:
| 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 wrote:
| 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 wrote:
| 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
| zer00eyz wrote:
| >> 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 wrote:
| 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 wrote:
| You mean on some individual person's laptop when that
| person remembers to run it?
| keybored wrote:
| Like most things.
| zer00eyz wrote:
| 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...
| MajimasEyepatch wrote:
| 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.)
| keybored wrote:
| > 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.
| sunshowers wrote:
| 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
| abathur wrote:
| 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
| Terretta wrote:
| 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 wrote:
| In our projects 80% of renovate updates are broken PR-s. In
| theory it should save work, but it just generates more.
| nonethewiser wrote:
| But are they broken because of renovate? Or just the underlying
| dependency updates?
| tiborsaas wrote:
| 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 wrote:
| 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 ;)
| aswihart wrote:
| 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 wrote:
| 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.
| nikolay wrote:
| 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 wrote:
| 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
| nikolay wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-12 23:00 UTC)