I d thought I d ask how people manage Dependabot hell in the

Question

I d thought I d ask how people manage Dependabot hell in their organizations We have a feature team based model so there s not clear ownership on any particular repo Keeping up with Dependabot updates for 3rd parties is a struggle We ve debated auto merging minor version updates but given how bad actors have tried to exploit bad package updates it feels wrong to go this way but the volume of updates is hard to keep up with

Liora Milbaum · Answer

I m using Renovate which is doing the same as dependabot but more and better From my experience there is no one way fit all There are many considerations to take into account My idea is to start small MVP and continuously improve according to the feedback requirements which pile up

Phillip Verheyden · Answer

we did a lot of hand wringing around turning on automated dependabot approvals but once we did we never looked back It has become pretty crucial to our process We have the advantage though of having fantastic automated test coverage gt 85 across every one of our services I would feel a lot less good about it if we did not have good test coverage We ve been operating with auto approving both minor and patch updates for gt 1yr In that year there is only a single breaking change that was merged in an upgrade to boto across thousands of merged PRs We caught it before it made it to customers though via some manual testing We have been really happy with it but as < Liora Milbaum> said YMMV gt but the volume of updates is hard to keep up with another strategy could be to tone down the frequency of updates for instance only have dependabot check for updates once a week

Phillip Verheyden · Answer

if you re interested in auto approve this is the GitHub action we use ```name Dependabot auto approve on pull request target permissions pull requests write From the docs at jobs dependabot runs on ubuntu latest if $ github event pull request user login == dependabot bot steps name Dependabot metadata id metadata uses dependabot fetch metadata v1 3 0 with github token $ secrets GITHUB TOKEN name Auto approve minor or patch updates if | steps metadata outputs update type == version update semver minor || steps metadata outputs update type == version update semver patch run gh pr review approve $PR URL env PR URL $ github event pull request html url GITHUB TOKEN $ secrets GITHUB TOKEN ``` and then we also flip on auto squash merge which you have to enable at the repo level I believe for all dependabot PRs once they are approved ```name Dependabot auto merge on pull request permissions pull requests write contents write Mostly from jobs dependabot runs on ubuntu latest if $ github event pull request user login == dependabot bot steps name Dependabot metadata id metadata uses dependabot fetch metadata v1 3 0 with github token $ secrets GITHUB TOKEN name Enable auto merge for Dependabot PRs run gh pr merge auto squash $PR URL env PR URL $ github event pull request html url GITHUB TOKEN $ secrets GITHUB TOKEN ```

Kyle Campbell · Answer

Thanks We re still in the hand wringing phase we did turn down to once a week but it s still a lot of PRs We were thinking of doing the auto approve like you are doing < Phillip Verheyden> but glad to hear that it s worked well for you We had thought about Renovate also a while ago but it may also be worth a rethink

Liora Milbaum · Answer

With renovate you can generate one PR for multiple updates That saves us a lot of effort

Jim Park · Answer

Thanks for the suggestions in this thread dependabot hell is real

Michel Loiseleur · Answer

We re using renovate here too Like < Liora Milbaum> this capacity to in one consistent PR really helped us For some dependencies that are updated multiple times per day we grouped AND to one PR per week