dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.61k stars 981 forks source link

Add support for multiple update_schedules / update_type combos for a single ecosystem / directory #1778

Open shleeable opened 4 years ago

shleeable commented 4 years ago

Hey, I'd love to be able to trigger and receive PRs for security updates on a live schedule. and my regular scheduled all updates weekly.

The following is a mock for my config.yml -- obviously fails the validator as a dupe atm :)

version: 1

update_configs:
  - package_manager: "ruby:bundler"
    directory: "/"
    update_schedule: "weekly"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "all"

  - package_manager: "javascript"
    directory: "/"
    update_schedule: "weekly"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "all"

  - package_manager: "ruby:bundler"
    directory: "/"
    update_schedule: "live"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "security"

  - package_manager: "javascript"
    directory: "/"
    update_schedule: "live"
    allowed_updates:
      - match:
          update_type: "security"
asciimike commented 3 years ago

This is equally valid in a v2 config world, and is something we're considering for the future.

natlibfi-jonollil commented 2 years ago

Would love to have this feature. Hoping to have minor update merging automagicaly if passes the tests and send PR to lead devs for major updates. Example .yml

version: 2
updates:
  # Minor updates to npm production dependencies daily
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "06:45"
      timezone: "Europe/Helsinki"
    versioning-strategy: lockfile-only
    labels:
      - "npm minor dependencies"
    allow:
      - dependency-type: "production"

  # Major updates to npm dependencies weekly @tuesday
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "07:00"
      timezone: "Europe/Helsinki"
    versioning-strategy: increase-if-necessary
    labels:
      - "npm major dependencies"
    reviewers:
      - "foobar/js-lead"
mariusburfey commented 2 years ago

Would love to have this feature. Hoping to have minor update merging automagicaly if passes the tests and send PR to lead devs for major updates.

This is exactly our use case. I would appreciate it very much.

adamniedzielski commented 2 years ago

The use case for my team is updating production dependencies weekly and dev dependencies monthly.

jamime commented 2 years ago

I'm also after this functionality.

I'd like to allow the default of 5 PR's for external dependencies, but unlimited PR's for dependencies from my organisation.

elstgav commented 1 year ago

Are there any possible workarounds for this? I have the exact same use case as @jamime

I’d like to allow the default of 5 PR’s for external dependencies, but unlimited PR’s for dependencies from my organization.

davidmurdoch commented 1 year ago

I'd like to enable security updates for all packages, but version updates for only a handful.

ianks commented 1 year ago

We just tried hacking around this with:

directory: "./" # instead of directory: "/"

This bypassed dependabot's validation, so we'll see what happens next...

UPDATE: Doesn't work.

snesm commented 1 year ago

Would like to do something similar for daily checks for dependencies with security vulnerabilities:

  # Security only daily
  - package-ecosystem: "npm"
    directory: "/mysite"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 0
  # All packages weekly
  - package-ecosystem: "npm"
    directory: "/mysite"
    schedule:
      interval: "weekly"
ff137 commented 1 year ago

Is this ... possible yet?

To configure more than one schedule for the same ecosystem.

Pinging active contributors: @brrygrdn @deivid-rodriguez @mctofu @Nishnha @jakecoffman

This seems like quite a prevalent question, and the issue is still open. Apologies if I've overlooked an obvious answer.

As far as I can tell the documentation on scheduling doesn't cover any advice to the natural scenario of wanting 2 separate schedules. Any feedback will be appreciated

sophiewigmore commented 11 months ago

Hey, I'm also interested in this feature so that we can bump our direct / indirect go.mod dependencies on different schedules

alekgosk commented 9 months ago

Hey I also stumbled upon the same problem, are there any potential workarounds available?

What we would like to achieve (for the same ecosystem = bundler):

castastrophe commented 9 months ago

Another use-case if it helps with prioritization:

A project at Adobe, Spectrum web components, consumes styles from a source project, Spectrum CSS. Though it has a weekly cadence for other dependencies, this base styles library is critical and so the Spectrum web components projects wishes to set up daily version checks to ensure alignment with the latest. This daily check also wants to assign different owners and use distinct labels. It is not ideal to group the styles dependency because those packages are independently versioned and all components might not be updated at the same time.

version: 2
updates:
    - package-ecosystem: 'npm'
      directory: '/'
      schedule:
          interval: 'weekly'
          day: 'tuesday'
          time: '12:00'
          timezone: 'America/Los_Angeles'
      open-pull-requests-limit: 5
      ignore:
          - dependency-name: '@spectrum-css/*'
      reviewers:
          - 'xxx'

    # This sets up a daily check for Spectrum CSS updates
    # focused on the @spectrum-css/* packages
    - package-ecosystem: 'npm'
      directory: '/'
      schedule:
          interval: 'daily'
      allow:
          - dependency-name: '@spectrum-css/*'
      labels: ['xxx']
      assignees:
          - 'xxx'

link

alecgibson commented 6 months ago

We just hacked our way around this by actively setting target-branch: main for one config, and leaving it unset for the other config (obviously only limited to 2 configs)

lubo commented 6 months ago

@alecgibson's workaround seems to work for me. See my dependabot.yml.

torokati44 commented 3 months ago

Hey, I'm also interested in this feature so that we can bump our direct / indirect go.mod dependencies on different schedules

Same but with Rust/Cargo! (Also, with different grouping, not just schedules.)

kahagerman commented 1 month ago

We just hacked our way around this by actively setting target-branch: main for one config, and leaving it unset for the other config (obviously only limited to 2 configs)

It appears to also be possible to use target-branch: MAIN (or other uppercase/lowercase combinations) to get more than two configs.

Edit: Doesn't work.