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.
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.
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.
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.
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.
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.
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.
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.
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.
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)?
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.
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.
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
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 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.
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.
>> 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.
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.
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.
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.
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.
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.
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.
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 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...
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.
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).
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 ;)
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.
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.
Anyhow, this is useful to rollout dependabot.yaml config at scale: https://github.com/github/evergreen