Configuring the Depfu Scheduler - Understanding PR limits

Dependency updates are important, but almost always not more important than the work your team is doing.

At Depfu our goal is to build a service that really helps your team stay up-to-date without getting annoying or in the way.

Limiting concurrent builds

Most CI services and systems have a limit of concurrent builds. Depfu tracks how many builds are currently running for your Github organization and schedules new updates so that we never use more than 1 concurrent slot of your CI. This hopefully leaves enough room for your other work and prevents Depfu from hogging your CI when there are a lot of updates at the same time or when we have to rebase multiple open PRs.

You can configure this limit for your whole organization in the org settings:

Limiting in progress dependency updates

The “work in progress” limit is a core concept from Kanban. Limiting the amount of WIP improves throughput and reduces the amount of work “nearly done” by forcing the team to focus on a smaller set of tasks.

We’re seeing that the most successful teams using Depfu merge pull requests quite often and not leaving many of them open at the same time. If pull requests start to pile up it gets harder to handle them and also the chance of merge conflicts gets bigger. Depfu does handle merge conflicts automatically, but it’s causing more work for your CI, because it needs to run the build again for all the “rebased” branches.

By default the limit for open Depfu pull requests on a repo is 7. If you’re merging PRs regularly you’ll never notice the limit and if you’re behind on merging it prevents you ending up with a huge list of open PRs. All further incoming updates are queued and are also shown in the Depfu Dashboard in the queued section. As soon as you’re below the limit again we’ll send you the queued up updates.

You can change the PR limit in the settings for your repo: