Dependabot-core: Per repo daily bump scan time setting rather than global

[davidgoate]

If the org has a large number of repos and all the bumps happen at the same time (e.g. 05:00 UTC) then the CI such as jenkins gets immediately hit with a large number of PR's which causes the executors to get very busy. Would be good to stagger them, perhaps per repo or some delay between opening PR's.

[greysteil]

Interesting, thanks for the feedback David (and sorry for the slow reply).

For your use case, is it not enough to be able to set the update run time to be in the middle of the night? It would totally be possible for me to add per-repo config, but I don't want to add the complexity if it can be avoided.

[davidgoate]

I've reduced the number of executors on the jenkins node. It was probably a bigger issue the first time i added dependabot. I added all my repos at once and on the first run each one had 5 PR's open so i had approx 40 builds all triggered at 5am. I still think the feature could be useful but not crucial

[greysteil]

👍 - I'm going to keep this open but not prioritise it in that case. I'll keep trying to mull over a simple solution to it, too.

Note: We probably also want you to be able to set the day-of-week for updates at a per repo level, if the solution is to set the time of day at that level.

[simondel]

In my case, the project we're working is mainly a spare time project. Right now, I sometimes have time to merge some Dependabot PRs during breakfast but not always because the builds may still be running. (We cannot automerge due to branch policies)

Either scheduling all jobs earlier or allowing set a time to schedule a repo's jobs would both work for us.

[davidgoate]

@simondel you can set a global time for all repos to run already in the advanced settings, so you could change all of your bumps to run 3/4 hours earlier for example I think this would solve your issue. I think the default is 05:00 UTC but you can modify this in your org settings.

[simondel]

@davidgoate Awesome! I didn't look at the settings there. I only looked at the settings in the repo. Thanks :)

[Jym77]

Another use case where a per-repo bump time would be useful:
I have dependabot on many repos, currently on a weekly bump. Since they are all using Python, when there are several updates in a given week, I spend my Monday morning swamped in going through dependabot (and manually @dependabot rebase because auto rebase was just killing our CI which has only 5 concurrent builds…) That is quite a lot of arid and boring work.
I've been considering moving to monthly bumps, to reduce the frequency of this (I don't need my deps to be that up-to-date, so monthly is good), but then the amount of work needed on the 1st of each month will be pretty bad…

Would be nice to have a per-repo day of the month/week bump (rather than a global one) to spread the workload (both human and CI) more evenly rather than everything on the same day.

Could even be a "first/second/third/fourth Monday of the month" to get into a slight routine of "Monday I'll do some dependabot work" rather than random days of the week.

I could also push for a per-dep bump time. Grouping bumps of one repo all together creates some extra work for all the rebases since we have to merge one by one. Whether it's only CI (auto-rebase) or also human (manual rebase) work, it's quite bad and not that necessarily. Having each repo bumping one dep every day allows to merge before the next bump comes, and thus avoid the rebase work.

[bwebster]

I also want to support the idea of making the day and time configurable via the yaml file. In our case many different teams are using dependabot, but specific teams using weekly updates would like to be able to customize the day of the week the PRs are opened to better align with team schedules (like on-call handoffs or iteration boundaries).

Also, confusingly, the PR description being generated right now incorrectly states that the day and time are configurable via the yaml file. Here's an excerpt from a recent PR opened by dependabot:

Additionally, you can set the following in the .dependabot/config.yml file in this repo:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• ...

[greysteil]

Good point on the confusing PR description text - I've just updated t hat.

On more per-repo configurability, I'm 👍 on that but we're a small team and focussed on integrating Dependabot into GitHub for the next few months.

[AlCalzone]

I think this idea deserves some more focus. I've got a small number of repos which are scanned weekly. After that scan I've got about 40-50 PRs with updated dependencies, each triggering about 10 builds on Github Actions and/or Travis CI.

Every week, about half of those PRs have failed and need to be manually restarted because some builds randomly hit rate limits while installing Node.js. Having the builds stretched out about a longer time should alleviate those issues.
I'm already running those builds in the middle of the night, so that won't help.

[infin8x]

This is supported by GitHub-native Dependabot: https://docs.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates#scheduleinterval. See this blog post for how to migrate from Dependabot.com: https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/