skip to content

In GitHub's dependabot.yml, how do ignore and allow rules control which bumps you get?

level: seniorimportance: should knowfreq 40%

answer

  1. One is a whitelist, one is a subtraction
  2. dependency-type direct is the big lever
  3. You can refuse a range or a bump size
  4. Some conditions live outside the file
  5. Exclusions never expire on their own

basics

~20 s

An allow block whitelists what Dependabot will consider at all, by dependency-type such as direct or production. An ignore block subtracts specific packages, version ranges, or bump sizes from what it proposes. Both live inside a single updates entry.

solid answer

~40 s

`allow:` is inclusive and narrows the field: entries take a `dependency-name` glob and/or a `dependency-type` of `direct`, `indirect`, `all`, `production` or `development`. Setting `dependency-type: direct` is the strongest noise reduction available, because it stops Dependabot proposing bumps for packages you never declared. `ignore:` is subtractive: each entry names a `dependency-name` (globs allowed) plus optionally `versions` (ranges you refuse) or `update-types` (`version-update:semver-major`, `-minor`, `-patch`). You can also create ignore conditions from a pull request with `@dependabot ignore this major version`, and inspect them later with `@dependabot show <dependency> ignore conditions`. The senior point is that both are permanent until someone deletes them: an ignore added during a release freeze is still silencing that package a year later, so they need a review cadence and a comment explaining why.

code

yaml · 15 lines
yaml
version: 2
updates:
  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      - dependency-type: "direct"
    ignore:
      # Majors are planned migrations, not bot work. Revisit 2026-Q4.
      - dependency-name: "org.springframework.boot:*"
        update-types: ["version-update:semver-major"]
      # 4.x broke our connection pooling; stay on 3.x until fixed upstream.
      - dependency-name: "com.example:legacy-client"
        versions: ["4.x"]

go deeper

for a junior

Know that GitHub's dependabot.yml can be told to skip specific dependencies or version jumps, and that the two blocks are named allow and ignore.

for a middle

Be able to write both blocks: allow with dependency-type direct or production, ignore with dependency-name plus versions or update-types. Know the semver update-type strings.

for a senior

Show that you treat exclusions as debt: narrowest possible scope, a written reason, a review cadence, and awareness that alerts keep firing regardless of what updates you suppressed.

for a principal

Own the governance angle — who is allowed to add an ignore, how the organisation notices a repository that has quietly opted out of maintenance, and how you keep exclusion lists visible in review rather than buried in bot state.

## Two opposite tools `allow` and `ignore` sit in the same `updates:` entry and pull in opposite directions. `allow` defines the universe Dependabot is permitted to consider. `ignore` removes things from whatever universe is left. If you write no `allow` block, the default is the ecosystem's normal behaviour for direct dependencies (with security updates still reaching transitive ones through alerts). ## allow Each entry accepts `dependency-name` (a glob) and `dependency-type`. The types are: - `direct` — only packages declared in your manifest. - `indirect` — only transitive packages. - `all` — both. - `production` / `development` — the ecosystem's own scope split, where it has one. The most common production configuration is a single entry with `dependency-type: direct`. It is a blunt but effective lever: you stop receiving routine churn for packages you did not choose, while advisory-driven security work still surfaces through alerts. `allow` with a `dependency-name` glob is how a team says "track this vendor's SDK closely and nothing else" on a repository nobody has time to maintain broadly. ## ignore Each entry needs a `dependency-name` and then narrows what is refused: - `versions` — one or more version constraints you will not accept, e.g. `"4.x"` or `">= 5.0.0"`. Use this to sit out a specific bad release line. - `update-types` — `version-update:semver-major`, `version-update:semver-minor`, `version-update:semver-patch`. Use this to say "minors and patches yes, majors never automatically". An entry with neither modifier ignores the dependency completely. ## The comment-driven variant Dependabot also accepts ignore instructions as pull-request comments: `@dependabot ignore this major version`, `@dependabot ignore this minor version`, and `@dependabot ignore this dependency`. These close the PR and record the condition in Dependabot's own state — **not** in your `dependabot.yml`. That is the trap: six months later nobody can explain why a package stopped moving, because there is nothing in the repository to read. `@dependabot show <dependency> ignore conditions` lists what is currently in effect, and the corresponding `@dependabot unignore` commands remove them. If you intend an exclusion to be durable, write it in the file where it is reviewable in a diff, and treat the comment form as a temporary convenience. ## The risk that makes this a senior question An over-broad ignore is silent risk. `dependency-name: "org.springframework.*"` with no modifiers looks tidy and quietly opts a whole framework out of routine maintenance. When an advisory eventually lands on one of those packages, you have an alert on the Security tab and, depending on how the rule is scoped, possibly no pull request to merge — and the bump you now need is a two-year jump rather than a patch. The defensive habits are: - Prefer the narrowest form: ignore a *version range* you know is broken, not the package. - Prefer `update-types: ["version-update:semver-major"]` over a blanket name ignore. Majors are the ones that genuinely need a human; minors and patches are what keeps you close to the patched version. - Comment every ignore with why and when it should be revisited — YAML comments survive in the diff and are the only durable place that reasoning lives. - Re-read the ignore list on a cadence. It is a debt register, and nobody ever reads it unless it is scheduled. ## Interaction with alerts Whatever you configure, Dependabot **alerts** keep firing: suppressing an update never suppresses the finding. That is the safety net, and it is also the argument for keeping alerts routed to a human even on a repository where you have narrowed updates to almost nothing. If you genuinely want an alert suppressed too, that is a separate decision — dismissing the alert with a reason, or an organisation auto-triage rule — and it should be made deliberately rather than as a side effect of a YAML glob. ## Putting it together A realistic senior configuration for a mature service: `allow` limited to `direct`, `ignore` entries only for majors of the two or three frameworks whose upgrades are project-sized, plus a dated comment on each, and a review of the ignore block every quarter. That produces a stream of small mergeable bumps, keeps big migrations as explicit planned work, and never hides a vulnerability.

  • You add @dependabot ignore this major version on a pull request. Where does that rule live?
    In Dependabot's own state for that repository, not in dependabot.yml. Nothing in the repository records it, so it is invisible in code review and easy to forget. Use @dependabot show <dependency> ignore conditions to list what is in effect, and prefer writing durable exclusions into the file instead.
  • Why is ignoring a whole package riskier than ignoring a version range?
    A name-level ignore opts the package out of routine maintenance indefinitely, so you drift far from current. When a fix is eventually required, the upgrade is a large multi-version jump under time pressure instead of a patch bump. A version-range ignore sits out one bad release line and lets normal updates resume afterwards.
  • Does narrowing allow to direct dependencies leave transitive vulnerabilities unmonitored?
    No. The dependency graph still resolves transitive packages and alerts still fire on them. What you lose is routine version churn for packages you never declared, which is usually the noise you wanted gone. Fixing a transitive vulnerability may still mean bumping the direct parent that pulls it in.

saying these in an interview costs you the question

  • Adds a blanket package-name ignore to silence noise
  • Thinks an ignore rule also stops the alert
  • Cannot say where comment-created ignore conditions are stored
  • Uses ignore where a version-range constraint was meant
  • Never revisits ignore entries once added

context

resolving links…