Dependabot update - switch to monthly?

[patjouk]

We're lagging a bit behind, maybe it's time to consider moving dependabot to monthly updates instead of weekly ones. We would still get GitHub notifications for security updates and it will be easy to open them from there.

Opinions @cadecairos @Pomax @mmmavis

[Pomax]

I don't think the issue is so much that it's frequent, but that there's single PRs for every single thing that got updated, and every PR that is reviewed good then invalidates every other PR. Doing that monthly would probably still be a very long time of pressing merge, waiting for CI to pass on the next item, pressing merge again, and all the while other people can't really land code because each merge invalidates their PRs as well. It might be a good idea to have a look at whether there's a way to have dependabot PRs that pass CI get auto-aggregated (that might be something we have to request over on the dependabot issue tracker), so that 10 PRs that all update things that don't affect each other can be landed as a single PR without blocking everyone's ability to get "real" changes landed.

[mmmavis]

Agreed with what @Pomax said.

Also wondering if we could adjust the frequency from weekly to bi-weekly for the time being.

[cadecairos]

Doing updates individually is something we probably want to keep, since it can surface issues related to a specific change.

The real issue we have is that piplock files are implemented foolishly and constantly cause merge issues when software unrelated to the actuall version bump get incremented (looking at you boto3)

[Pomax]

That's part 2 of the real issue, but from a dev side, the real issue is that it easily takes an hour to merge 10 dependabot PRs that all pass CI, because every PR gets rebased and CI has to rerun after every merge into master. And not just for the person doing them, but also for everyone else whose "green" PRs keep turning "out of date" with every dependency bump merge, too.

[patjouk]

Let's see how mergify is helping. If dependabot is still eating too much of our time, I'll reopen this ticket and investigate again.