After a while though, I started getting a bit annoyed with the workflow around it.
Even with grouping, we'd sometimes end up with multiple PRs, and every PR would trigger our CI pipeline since we obviously still wanted to make sure the dependency updates didn't break anything.
Our CD was also set up so that whenever something was merged into the default branch, it would get deployed to our dev environment. So if Dependabot opened 4 PRs, we'd run CI for all 4, review/merge them separately, and potentially deploy 4 times.
It got even more annoying on some projects where we had to maintain both a dev and main branch. We ended up doing workarounds around Dependabot and sometimes basically had two PRs for the same updates.
It's not a massive problem, but once you have a few repos it starts adding up. More GitHub Actions minutes, more PRs to go through, more deployments, and you still occasionally have an update that needs to be tested or checked manually.
So I started playing around with a different approach and ended up building greenbatch.
It's a Claude Code skill that finds dependency updates like Dependabot does, but instead of immediately opening PRs for them, it actually tries the updates and runs the project's tests first.
The updates that pass get batched together into a single PR. If something fails, or greenbatch isn't confident that the update can be validated automatically, it leaves it out and reports it so you can take a look yourself.
We set it up to run once a week and it's been working pretty well for us. We basically went from having a bunch of dependency PRs going through CI individually to getting one PR containing the updates that have already been tested.
It also ended up cutting down our GitHub Actions usage a decent amount, which was one of the main reasons I started looking into this in the first place.
I ended up open sourcing it in case anyone else has the same problem: