Show details from timed-out update runs

[swegner]

I just tried integrating dependabot on a personal repo (swegner/beam) using Gradle. I see that dependabot "bumped" an hour ago, but I don't see any output. No pull requests are open, and I can't tell whether I have it properly configured.

It'd be nice if dependabot gave some output about what happened in its last run. On a successful run, this could include:

1. The head commit used.
2. What build system was used and what build files it found for that build system
3. The dependencies detected and their current version
4. A status for each dependency: whether it is known up-to-date / stale, or unknown.
5. Action that was take for stale dependencies.

[greysteil]

Thanks for giving Dependabot a try! I've just looked at our logs and can see that, unfortunately, that update run timed out. It's the one status that we don't give any feedback for - I should definitely fix that, at the very least, and will change the title of this issue accordingly.

As a more general point about Dependabot's Gradle support - it's still in Alpha and unlikely to be able to handle large projects like Beam just yet. I'd like to get it there, but it's a way off yet. Our support for every other package manager is a lot more advanced, and I wouldn't expect problems like this one to occur for them.

[greysteil]

It's also worth mentioning that the core for Dependabot is open source over at https://github.com/dependabot/dependabot-core, and if you fancy having a poke around the Gradle support you'd be very welcome! Java is probably my weakest languages, so apologies if it's a bit of a mess right now!

[swegner]

Thanks for the quick feedback. For full transparency, I likely won't have a chance to look into improving Gradle support. But I'll keep an eye on this issue and can give it another try.

[mszabo-wikia]

Note: this still seems to be an issue for large Gradle projects. Recently we enabled Dependabot for our Gradle monorepo which contains over 110 subprojects; the subprojects were correctly registered but no PRs arrived. Registering some subprojects manually did result in PRs for those subprojects, so this seems to indicate a timeout issue.

[greysteil]

That would make sense - with very large projects like that Dependabot will be making hundreds of calls to GitHub to fetch each of the dependency files (it doesn't clone your repo for security reasons). I'd love to make that better in future.

[erdnaxeli]

What is the timeout time?

[duhseekoh]

I'm seeing failures at the 30 minute mark. Our yarn.lock file, which is big, but not out of the ordinary can't be processed by dependabot for within that timeframe for some reason. In the dependabot logs, only a handful of out the many dependencies get checked. We've been missing a lot of updates because of that. :(

[erdnaxeli]

I'm seeing failures at the 30 minute mark. Our yarn.lock file, which is big, but not out of the ordinary can't be processed by dependabot for within that timeframe for some reason. In the dependabot logs, only a handful of out the many dependencies get checked. We've been missing a lot of updates because of that. :(

I have the same kind of problem with a Pipenv file. It tooks some time when running manually but no more than 5 minutes, I don't understand.

[jeffwidman]

The code around timeouts has changed a lot since this issue was filed/updated. In fact, it's on a completely new infrastructure backend. So I'm going to close this, but if you are still seeing problems, please file an issue and we can look at what is happening in that specific case.