Per dependency bump schedule

[RohanNagar]

I'm not sure if there is already an open issue/backlog item for this, but it would be nice to be able to set bump schedules on a per-dependency basis.

For example, I typically want daily updates to my repositories so I can get the latest packages asap, except there are a few dependencies that release daily that I don't want to have to review and merge every day. For these few dependencies (usually AWS packages), I would want them to be bumped weekly or even monthly.

Right now I have this repository set to bump weekly because of those frequently updated packages, so I get a big dump of everything on Mondays. It would be nice to change it to daily for all packages except the frequently updated ones.

Thanks for all your work on dependabot!

[greysteil]

Interesting, thanks for the feedback. Sounds like it would be nice to have a middle ground that stops short of asking Dependabot to completely ignore a dependency.

I'll have a think on this - we could possibly add a custom_schedules section to the the config file to support it. It's not likely to be something we add before June (we have our work cut out) but I'll keep this open and revisit next time we're prioritising.

Thanks for using Dependabot!

[BPScott]

Hi folks,

Popping in to say this my team would find this feature really useful too. For context:

I work on the design-system team at my company and we publish a public npm package that is then consumed by the various app repos that make up our web presence. Ideally we want our consumers to be notified of our releases ASAP as we want people to keep up to date. For our biggest consumers we even take responsibility for merging updates as soon as they are released.

At the same time we appreciate our developer buddies would prefer a weekly cadence for other updates so they're not overwhelmed.

It would be fantastic to be able to configure a repository to say:

• Have a default of update_schedule: 'weekly'
• Package names matching@shopify/polaris should use update_schedule: 'live'

[GaryGSC]

Bump.

[foglerek]

Any chance this could be considered? It would be very useful for cases where certain dependencies need to be as fresh as possible (such as browserslist/@babel-compat), but most other dependencies should have a weekly or even monthly cadence to reduce noise.

[RevolutionTech]

...we publish a public npm package that is then consumed by the various app repos that make up our web presence. Ideally we want our consumers to be notified of our releases ASAP as we want people to keep up to date...

At the same time we appreciate our developer buddies would prefer a weekly cadence for other updates so they're not overwhelmed.

We have a very similar use case, although just wanted to add that we use Dependabot to update dependencies in the package that we publish and then use Dependabot in the projects that use this package.

Since we update dependencies monthly, the updates for the package and the updates for the projects come at the same time. This really means that unless we manually re-execute Dependabot on all of the projects after updating the package, all of the projects' dependencies from the package will be consistently one month old.

Having the ability to mark our package to be updated as live would be great because then we could update the package first, push out a new version, and then the latest version of the package could be merged in along with the remaining Dependabot PRs for that month without manually running Dependabot on every project.

[tsauvajon]

This is also a blocker for us. We want most dependencies to be as fresh as possible, but we have dependencies that are deployed daily, making Dependabot create an insane amount of PRs.

I tried a similar approach as others in this issue or one of the duplicates:

version: 1
update_configs:
  - package_manager: "go:modules"
    directory: "/"
    update_schedule: "live"
    ignored_updates:
      - match:
          dependency_name: "github.com/something/[...]"
      - match:
          dependency_name: "github.com/aws/aws-sdk-go"
  - package_manager: "go:modules"
    directory: "/"
    update_schedule: "weekly"

[shavo007]

I agree with sentiments here. Otherwise you get whats known as "dep fatigue" (actually i made that up!)

I used renovate before where you could slice and dice as you wish with diff schedules and presets. I was hoping dependabot would do the same.

[jmauerhan]

Would also appreciate this, we want to look for most updates on a weekly basis, and a few daily.

[JWCook]

This is especially relevant for plugin/extension type projects that are closely coupled with another project (typically a framework or other large project). In those cases, I want to bump the version of the "integration" dependency as soon as it's available to test for compatibility, and bump the rest of the dependencies less frequently.

Some non-ideal workarounds include:

• Use a scheduled workflow in GitHub Actions to regularly test against the latest version of the integration dependency
• Use dependabot for only the integration dependency and handle other updates manually

[Nezteb]

One of my colleagues wrote a blog post about why this functionality would be useful in dependabot; currently we have a custom CircleCI script for this.

[vishen]

+1 this is also a requirement for something my team is working on.

[cbrgm]

Same here, we are using AWS go dependencies in our projects and as they're releasing a new version on a daily basis it's really hard to keep up with dependabot PRs.

[jtrein]

+1 would be really useful

[abdulapopoola]

Update: We've started doing some grouped updates work! This particular issue might not be part of the first ship but if you want to track our updates, do follow #1190.

[abdulapopoola]

Closing this out as we've officially released grouped version updates; please feel free to reopen or reach out if there are more questions or feedback.

[jeffwidman]

This should get re-opened, the existing grouped version updates functionality doesn't provide this AFAICT.

[elstgav]

Agreed— @abdulapopoola or @carogalvin can we reopen this? I don’t believe the grouping feature allows for separate schedules