Dependabot runs for cargo dependencies time out #2450

Current behavior 😯

We didn't get a Dependabot PR to upgrade cargo dependencies today, though we should have, because when Dependabot runs on this repository for that ecosystem, it times out. This can be seen in recent runs shown at:

https://github.com/GitoxideLabs/gitoxide/network/updates/9454592/jobs

For convenience, a couple of those recent timed-out runs are:

• https://github.com/GitoxideLabs/gitoxide/actions/runs/22539861905/job/65293355364
• https://github.com/GitoxideLabs/gitoxide/actions/runs/22547712209/job/65312693131

I've rerun it a few times, and I plan to keep rerunning it throughout the day, but so far it has consistently timed out. I don't know of any reason it's taking too long, besides that this workspace has a lot of complex dependencies whose transitive dependencies are hard to resolve.

There are some benefits of using Dependabot, so I hope to fix this somehow. The cooldown feature seems to work pretty reliably in this repository, including even for transitive dependencies, and it doesn't have corresponding direct functionality in cargo.

I think the usual strategy for overcoming persistent Dependabot problems is to switch to Renovatebot. That's an excellent alternative in general, but while it has a feature that corresponds to cooldown, I don't think that feature works nearly as thorougly with cargo, since I think it is built to rely on integration with corresponding features in programs like cargo, at least for the management of transitive dependencies.

My understanding is that it is specifically because Dependabot does so much stuff separate from running cargo that it is both able to have a more effective cooldown feature for our needs and able to take massive amounts of time to do its work even when a more closely cargo-based implementation would operate faster.

Expected behavior 🤔

It's fine if it takes a long time, but it should be complete.

Though not ideal, it would also be sort of okay if it often timed out, but if rerunning it was a reliable way to get it to work. However, this would soon stop being okay, if we end up getting more dependencies over time as more gix-* crates are implemented.

Git behavior

Not applicable. Git does have some Rust code now, but I don't think it has lots of complex dependencies as here, so no analogous problem is even in principle applicable, if I understand correctly.

Steps to reproduce 🕹

See above.

I've also reproduced this in my fork. I was aware of it a couple weeks ago, but I hoped it either would go away or that the runs would somehow work better in this upstream repository. In the past, I have sometimes had timeouts in my fork even when Dependabot works here. But it's not working here now.