docs-site/developers/dependabot.mdx
Config lives in .github/dependabot.yml.
This page is for maintainers: how PRs are grouped, which ones to merge,
and how to clear Rust advisories that Dependabot cannot fix on its own.
Version updates were accumulating faster than anyone reviewed them. Our solution is to fix grouping and slow the schedule, not turn updates off.
Security updates stay individual. Each advisory needs its own review (false positives are common, so we need to know which CVE actually matters). GitHub also does not apply open-pull-requests-limit to security PRs.
Four ecosystems: Cargo, npm (Yarn), Python (uv), GitHub Actions.
| Kind | When | Shape | What to do |
|---|---|---|---|
| Security | As soon as GitHub publishes an advisory. Ignores the schedule. | One PR per advisory | Review and land promptly, or close if it does not apply |
| Minor / patch | Quarterly | One grouped PR per ecosystem (*-minor-patch) | Merge if CI is green |
| Major | Quarterly, after a 30-day cooldown | One grouped PR per ecosystem (*-major) | Do not merge. Treat as a notification. If a bump is wanted, open a human PR for that package |
| GitHub Actions | Quarterly | One grouped PR (actions) | Merge if CI is green |
open-pull-requests-limit is 2 for Cargo / npm / Python (one slot for minor/patch, one for major) and 1 for Actions. That limit applies only to version updates. Security PRs are unlimited.
Cooldown is 7 days for ordinary version bumps (a short supply-chain window) and 30 days for majors (semver-major-days). Security updates skip cooldown.
Dependabot PRs are exempt from the linked-issue requirement.
format, cargo deny, and the existing suites still run;YN0028 / yarn install --immutable, Dependabot updated package.json and left yarn.lock stale. Check out the branch, run Yarn so the lockfile matches, and push;Land these first. Confirm the advisory actually affects this repo: Dependabot matches on version, not on whether we call the vulnerable API.
If the bump is a major, or CI fails, do not force the Dependabot PR through. Open a normal PR with whatever code or lockfile changes are required.
If we cannot bump yet, say so in the PR and follow the Rust ignore path below when cargo-deny is the failing check.
Low risk. Merge when CI is green. If one crate in the group breaks the build, do not merge the bundle, we should split or skip that crate.
Majors often need code changes. The grouped PR exists so we are not flooded with one PR per package. It is not meant to be merged as-is. Pick the package we actually want, open a dedicated PR, and leave the rest.
Actions are pinned by SHA. Dependabot security alerts are not generated for SHA-pinned actions but Dependabot still opens the quarterly grouped version PR and bumps those SHAs to the latest release. So there is no immediate security PR for a vulnerable action. That is an accepted trade-off: SHA pins stop tag-rewrite supply-chain attacks, at the cost of losing action alerts.
cargo-deny)CI runs cargo deny check on pushes and on PRs that touch Cargo.lock, Cargo.toml, or .deny.toml. Failures often look like Dependabot work but are not something Dependabot can finish, especially when the crate sits behind a git dependency.
Worked example: RUSTSEC-2026-0258 needed a reqwest bump inside the ankitects/linkcheck fork, not a one-line change in this repo.
RUSTSEC-… advisory and note the crate and patched versions.linkcheck, percent-encoding-iri, …):
Cargo.toml at the new rev.cargo update -p <crate> (and any other crates the advisory names) so Cargo.lock moves.cargo deny check locally before pushing..deny.toml [advisories] ignore with a comment stating why and what the alternative is. Existing ignores follow that pattern. Do not silence an advisory without a comment.Dependabot cannot update git rev pins. Those bumps are always manual.
open-pull-requests-limit cannot cap security PRs;default-days and semver-major-days.