Dependabot-core: Dependabot to run a "full" `cargo update`

[D4nte]

Hi,

Because our builds are quite lengthy, we are planning to do regular manual cargo update for the full lock file and let dependabot handle the Cargo.toml updates.

Thinking about it, it would be great if dependabot could do that for us: open 1 PR that does a full cargo update (not specific to one dependency). In other words, do all dependencies at once for cargo lock file updates only.

Then, for Cargo.toml dependencies update, do it dependency per dependency as usual.

What do you think?

Thanks.

[greysteil]

Thanks for the feedback @D4nte. We'd love to support this in future, but it would require quite a lot of rearchitecting of dependabot-core, which is set up around the concept of doing a single (top-level) dependency update in each PR.

I'll keep this open, as it's an option we'd like to consider in future, but I can't promise anything imminent on it. We think there are advantages to doing updates one at a time, so it's the flow we encourage, but I can understand the CI time consideration.

[sudara]

I love this idea, though I understand how it throws a wrench into dependabot's paradigm. As a part time maintainer, 1 PR a week for package.json updates as well as 1 PR for Gemfile.lock updates is exactly the speed that would be ideal for me.

I like dependabot a lot. I kept up with daily updates for a few weeks, but it's unfortunately been too much "paperwork" to have my projects regularly peppered with individual PRs — it can feel somewhat overwhelming without a larger team! I tried going "weekly" but that makes /pulls and slack very very noisy on the days it updates, even with auto-merge on.

In case it helps, my view on deps is "there's a few special ones that take careful work to upgrade; the rest I just want to keep up with and don't need to keep individually reevaluating". Maybe there could be a way to identify "batchable" dependency upgrades (such as patch/minor bumps on the majority of boring deps)...

[D4nte]

@sudara I think the only way to identify batchable is major vs minor version update. Otherwise, try and error would be the only option.

[greysteil]

Yeah, at the very least I think we want the option to let you group dependencies (there's another open issue following that), which would provide one option for the fix here (choose to group everything that's an indirect dependency).

We've had to spend quite a lot of time in the last few months focussing on scaling (Dependabot is twice the size it was at Christmas already) and it's been frustrating not to get to some of these bigger feature requests, but we will get to them, I promise 🙂

[merwok]

+1 from a Python developer. I like to group updates, and validate the result on a dev environment (but not one temporary env for each PR), so my workflow ends up being:

• read release notes and changelog in dependabot PRs
• merge security PRs very quick
• keep other PRs open for a week or more, until I have time to check them
• run a full update of my requirements files locally, to get one PR to deploy and check

Still happy to pay for the service of centralizing all info about updates, and sometimes have the comfort of doing the whole update from a browser (from release notes to deployment), but in the end I think 1 PR per update doesn’t fit. Maybe I should try setting up auto-merging and just learn to ignore update PRs and unsupervised deploys; but I think I would really like more options to control the workflow (this ticket or dependabot/feedback#5 or dependabot/feedback#318 or dependabot/feedback#185)

Cheers!

[mmstick]

Until this is done, Dependabot won't be useful for any of our Rust projects at System76. If a single project has:

• 5-10 crate dependency updates
• opening 5-10 merge request for dozens of Rust projects
• and each Rust project is backed by CI/CD scripts that run 4+ package builds per merge request
• and each individual package build takes between 5mins to an hour to build...

We'd never be able to get anything done :grimacing: Nor would our QA be able to reasonably test each individual merge request in a timely manner. One PR per week/month that simply runs cargo update && git add Cargo.{toml,lock} && git commit is honestly all we'd really need.

[jsoref]

Fwiw, we're switching to a branch for dependabot, so it can make a bunch of PRs into the branch, we merge them, and then merge that single combined branch into master. That way devs aren't stuck waiting for a series of merges to clear.

[thomaseizinger]

@mmstick

One PR per week/month that simply runs cargo update && git add Cargo.{toml,lock} && git commit is honestly all we'd really need.

Given we have GitHub actions now, this is easily scriptable! :)
I've already been thinking about creating one but just haven't had the time yet :D

[AArnott]

I want one aggregate PR for npm updates as well. Same for NuGet. With the option (say, when the PR build fails) @dependabot split to split the one PR into individual PRs for each package update.

It's quite alright (preferred even) if each top-level dependency update was in its own commit for that aggregate PR.