Configure advanced dependency update rules with dependabot.yml, including grouping, scheduling, and update strategies.

A platform team runs Dependabot version updates for a npm project on a weekly schedule. They are happy with the cadence but find that, immediately after merging one of Dependabot's pull requests, Dependabot force-pushes a rebase onto any other open Dependabot pull requests to resolve conflicts, which retriggers their continuous integration and consumes runner minutes they would rather conserve. They want Dependabot to stop rebasing its open pull requests automatically while still opening new ones on the weekly schedule. Which setting in the update entry produces this behaviour?

• ASet "open-pull-requests-limit: 0" so Dependabot holds back from touching pull requests, which has the side effect of suppressing the automatic rebase activity.
• BSet "schedule.interval: "weekly"" together with "rebase: false", a boolean that switches the rebasing engine off for the entry.
• CSet "versioning-strategy: "lockfile-only"" so Dependabot only updates the lock file, which avoids the conflicts that prompt the rebases.
• DSet "rebase-strategy: "disabled"" on the update entry so Dependabot stops automatically rebasing its open pull requests, leaving the weekly opening of new pull requests unaffected.check_circle Correct

Why A is wrong: This is tempting because the limit does throttle Dependabot, but "open-pull-requests-limit: 0" disables version updates entirely, so no new weekly pull requests would be opened either, which contradicts the requirement to keep raising them.

Why B is wrong: This is plausible because the intent matches, but "rebase" is not a valid dependabot.yml key; the field that controls this behaviour is "rebase-strategy", whose values are "auto" or "disabled", so "rebase: false" is ignored.

Why C is wrong: This confuses two unrelated controls; "lockfile-only" changes which files an update touches, not whether existing open pull requests are rebased, and it would also change the substance of every update rather than just stopping the automatic rebase.

Why D is correct: Correct: "rebase-strategy" defaults to "auto", which rebases open Dependabot pull requests when the target branch changes; setting it to "disabled" stops the automatic rebases and the extra CI runs they trigger, while the "schedule" still governs when new pull requests are opened.