deepskill

GitHub Dependabot 配置

dependabot

授权

配置和管理 GitHub Dependabot 的综合指南。适用于创建或优化 dependabot.yml、管理 Dependabot 拉取请求、配置依赖更新策略、设置分组更新、多仓库模式、多生态分组、安全更新配置、自动分流规则,以及其他与 Dependabot 有关的 GitHub Advanced Security(GHAS)供应链安全主题。对于 AI 编码 Agent 通过 GitHub MCP Server 执行的提交前依赖漏洞扫描,本技能引用 Advanced Security 插件(advanced-security@copilot-plugins)。在 Agent 需要于提交前扫描依赖中的已知漏洞时使用。

↓ 0 下载 ↗ 0 分享点击

介绍来源: author · github · b6483db44fb602654bca6a097185fcaddb305f97 参考来源

作者原文

Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests, configuring dependency update strategies, setting up grouped updates, monorepo patterns, multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill when an agent needs to scan dependencies for known vulnerabilities before committing.

SkillPi 解读

能完成的任务
GitHub Dependabot 配置
适合谁
请按作者原文中的适用场景判断。
输入和输出
以作者完整文档为准;本站未运行验证产物。
软件、账号及付费要求
使用前按完整文档确认软件、账号、费用及权限;由宿主核对并授权实际文件读写和外部服务。文档引用域名(非运行白名单):ghcr.io, github.blog, github.com, npm.example.com, npm.internal.example.com, pypi.example.com, repo.maven.apache.org 修改依赖更新、忽略或告警策略须先预览差异;不能把忽略依赖告警或自动合并示例当作已获授权。外部安全插件的安装和仓库权限另行确认。 外部工具按官方来源固定版本并单独核验;本站未安装或运行依赖。文件改动、外部发送、密钥和费用仍由使用者在宿主中逐项授权。
限制与区别
原文中的功能、版本状态和效果描述属于作者陈述;中文为对应翻译。仅核对固定版本及静态附件证据,不保证运行效果、外部服务或兼容性。
实测状态
未测试

权限与使用前检查

根据当前主文档自动整理,命中内容可能是示例或防护说明;不是实际权限声明,也未覆盖附件、外部依赖或运行行为。

未从主文档识别到上述常见操作,不能据此判断无需权限或没有风险。

文档引用的域名或地址

这些地址可能用于文档链接或示例,不是已批准的联网清单。使用前核对实际目的地及发送的数据。

  • github.blog
  • github.com
  • npm.example.com

本站展示提示不会授予权限。涉及文件改动、密钥、外部发送或费用时,仍由你使用的工具按需确认。

安全评级与访问范围

caution · 静态证据核验,不代表运行安全保证。

使用前按完整文档确认软件、账号、费用及权限;由宿主核对并授权实际文件读写和外部服务。文档引用域名(非运行白名单):ghcr.io, github.blog, github.com, npm.example.com, npm.internal.example.com, pypi.example.com, repo.maven.apache.org 修改依赖更新、忽略或告警策略须先预览差异;不能把忽略依赖告警或自动合并示例当作已获授权。外部安全插件的安装和仓库权限另行确认。 外部工具按官方来源固定版本并单独核验;本站未安装或运行依赖。文件改动、外部发送、密钥和费用仍由使用者在宿主中逐项授权。

使用前请由宿主核对并授权实际文件读写、外部服务和联网目的地;本站的核验不会授予任何运行权限。

原始 SKILL.md

---
name: dependabot
description: >-
  Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when
  users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests,
  configuring dependency update strategies, setting up grouped updates, monorepo patterns,
  multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub
  Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit
  dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill
  references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill
  when an agent needs to scan dependencies for known vulnerabilities before committing.
---

# Dependabot Configuration & Management

## Overview

Dependabot is GitHub's built-in dependency management tool with three core capabilities:

1. **Dependabot Alerts** — Notify when dependencies have known vulnerabilities (CVEs)
2. **Dependabot Security Updates** — Auto-create PRs to fix vulnerable dependencies
3. **Dependabot Version Updates** — Auto-create PRs to keep dependencies current

All configuration lives in a **single file**: `.github/dependabot.yml` on the default branch. GitHub does **not** support multiple `dependabot.yml` files per repository.

## Configuration Workflow

Follow this process when creating or optimizing a `dependabot.yml`:

### Step 1: Detect All Ecosystems

Scan the repository for dependency manifests. Look for:

| Ecosystem | YAML Value | Manifest Files |
|---|---|---|
| npm/pnpm/yarn | `npm` | `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock` |
| pip/pipenv/poetry | `pip` | `requirements.txt`, `Pipfile`, `pyproject.toml`, `setup.py` |
| uv | `uv` | `pyproject.toml`, `uv.lock` |
| Docker | `docker` | `Dockerfile` |
| Docker Compose | `docker-compose` | `docker-compose.yml` |
| GitHub Actions | `github-actions` | `.github/workflows/*.yml` |
| Go modules | `gomod` | `go.mod` |
| Bundler (Ruby) | `bundler` | `Gemfile` |
| Cargo (Rust) | `cargo` | `Cargo.toml` |
| Composer (PHP) | `composer` | `composer.json` |
| NuGet (.NET) | `nuget` | `*.csproj`, `packages.config` |
| .NET SDK | `dotnet-sdk` | `global.json` |
| Maven (Java) | `maven` | `pom.xml` |
| Gradle (Java) | `gradle` | `build.gradle` |
| Terraform | `terraform` | `*.tf` |
| OpenTofu | `opentofu` | `*.tf` |
| Helm | `helm` | `Chart.yaml` |
| Hex (Elixir) | `mix` | `mix.exs` |
| Swift | `swift` | `Package.swift` |
| Pub (Dart) | `pub` | `pubspec.yaml` |
| Bun | `bun` | `bun.lockb` |
| Dev Containers | `devcontainers` | `devcontainer.json` |
| Git Submodules | `gitsubmodule` | `.gitmodules` |
| Pre-commit | `pre-commit` | `.pre-commit-config.yaml` |

Notes:
- pnpm and yarn both use the `npm` ecosystem value.
- Prefer `uv` ecosystem value when `uv.lock` is present; otherwise use `pip`.

### Step 2: Map Directory Locations

For each ecosystem, identify where manifests live. Use `directories` (plural) with glob patterns for monorepos:

```yaml
directories:
  - "/"           # root
  - "/apps/*"     # all app subdirs
  - "/packages/*" # all package subdirs
  - "/lib-*"      # dirs starting with lib-
  - "**/*"        # recursive (all subdirs)
```

Important: `directory` (singular) does NOT support globs. Use `directories` (plural) for wildcards.

### Step 3: Configure Each Ecosystem Entry

Every entry needs at minimum:

```yaml
- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"
```

### Step 4: Optimize with Grouping, Labels, and Scheduling

See sections below for each optimization technique.

## Monorepo Strategies

### Glob Patterns for Workspace Coverage

For monorepos with many packages, use glob patterns to avoid listing each directory:

```yaml
- package-ecosystem: "npm"
  directories:
    - "/"
    - "/apps/*"
    - "/packages/*"
    - "/services/*"
  schedule:
    interval: "weekly"
```

### Cross-Directory Grouping

Use `group-by: dependency-name` to create a single PR when the same dependency updates across multiple directories:

```yaml
groups:
  monorepo-deps:
    group-by: dependency-name
```

This creates one PR per dependency across all specified directories, reducing CI costs and review burden.

Limitations:
- All directories must use the same package ecosystem
- Applies to version updates only
- Incompatible version constraints create separate PRs

### Standalone Packages Outside Workspaces

If a directory has its own lockfile and is NOT part of the workspace (e.g., scripts in `.github/`), create a separate ecosystem entry for it.

## Dependency Grouping

Reduce PR noise by grouping related dependencies into single PRs.

### By Dependency Type

```yaml
groups:
  dev-dependencies:
    dependency-type: "development"
    update-types: ["minor", "patch"]
  production-dependencies:
    dependency-type: "production"
    update-types: ["minor", "patch"]
```

### By Name Pattern

```yaml
groups:
  angular:
    patterns: ["@angular*"]
    update-types: ["minor", "patch"]
  testing:
    patterns: ["jest*", "@testing-library*", "ts-jest"]
```

### For Security Updates

```yaml
groups:
  security-patches:
    applies-to: security-updates
    patterns: ["*"]
    update-types: ["patch", "minor"]
```

Key behaviors:
- Dependencies matching multiple groups go to the **first** match
- `applies-to` defaults to `version-updates` when absent
- Ungrouped dependencies get individual PRs

## Multi-Ecosystem Groups

Combine updates across different package ecosystems into a single PR:

```yaml
version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    labels: ["infrastructure", "dependencies"]

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws*"]
    multi-ecosystem-group: "infrastructure"
```

The `patterns` key is required when using `multi-ecosystem-group`.

## PR Customization

### Labels

```yaml
labels:
  - "dependencies"
  - "npm"
```

Set `labels: []` to disable all labels including defaults. SemVer labels (`major`, `minor`, `patch`) are always applied if present in the repo.

### Commit Messages

```yaml
commit-message:
  prefix: "deps"
  prefix-development: "deps-dev"
  include: "scope"  # adds deps/deps-dev scope after prefix
```

### Assignees and Milestones

```yaml
assignees: ["security-team-lead"]
milestone: 4  # numeric ID from milestone URL
```

### Branch Name Separator

```yaml
pull-request-branch-name:
  separator: "-"  # default is /
```

### Target Branch

```yaml
target-branch: "develop"  # PRs target this instead of default branch
```

Note: When `target-branch` is set, security updates still target the default branch; all ecosystem config only applies to version updates.

## Schedule Optimization

### Intervals

Supported: `daily`, `weekly`, `monthly`, `quarterly`, `semiannually`, `yearly`, `cron`

```yaml
schedule:
  interval: "weekly"
  day: "monday"         # for weekly only
  time: "09:00"         # HH:MM format
  timezone: "America/New_York"
```

### Cron Expressions

```yaml
schedule:
  interval: "cron"
  cronjob: "0 9 * * 1"  # Every Monday at 9 AM
```

### Cooldown Periods

Delay updates for newly released versions to avoid early-adopter issues:

```yaml
cooldown:
  default-days: 5
  semver-major-days: 30
  semver-minor-days: 7
  semver-patch-days: 3
  include: ["*"]
  exclude: ["critical-lib"]
```

Cooldown applies to version updates only, not security updates.

## Security Updates Configuration

### Enable via Repository Settings

Settings → Advanced Security → Enable Dependabot alerts, security updates, and grouped security updates.

### Group Security Updates in YAML

```yaml
groups:
  security-patches:
    applies-to: security-updates
    patterns: ["*"]
    update-types: ["patch", "minor"]
```

### Disable Version Updates (Security Only)

```yaml
open-pull-requests-limit: 0  # disables version update PRs
```

### Auto-Triage Rules

GitHub presets auto-dismiss low-impact alerts for development dependencies. Custom rules can filter by severity, package name, CWE, and more. Configure in repository Settings → Advanced Security.

## PR Comment Commands

Interact with Dependabot PRs using `@dependabot` comments.

> **Note:** As of January 2026, merge/close/reopen commands have been deprecated.
> Use GitHub's native UI, CLI (`gh pr merge`), or auto-merge instead.

| Command | Effect |
|---|---|
| `@dependabot rebase` | Rebase the PR |
| `@dependabot recreate` | Recreate the PR from scratch |
| `@dependabot ignore this dependency` | Close and never update this dependency |
| `@dependabot ignore this major version` | Ignore this major version |
| `@dependabot ignore this minor version` | Ignore this minor version |
| `@dependabot ignore this patch version` | Ignore this patch version |

For grouped PRs, additional commands:
- `@dependabot ignore DEPENDENCY_NAME` — ignore specific dependency in group
- `@dependabot unignore DEPENDENCY_NAME` — clear ignores, reopen with updates
- `@dependabot unignore *` — clear all ignores for all dependencies in group
- `@dependabot show DEPENDENCY_NAME ignore conditions` — display current ignores

For the complete command reference, see `references/pr-commands.md`.

## Ignore and Allow Rules

### Ignore Specific Dependencies

```yaml
ignore:
  - dependency-name: "lodash"
  - dependency-name: "@types/node"
    update-types: ["version-update:semver-patch"]
  - dependency-name: "express"
    versions: ["5.x"]
```

### Allow Only Specific Types

```yaml
allow:
  - dependency-type: "production"
  - dependency-name: "express"
```

Rule: If a dependency matches both `allow` and `ignore`, it is **ignored**.

### Exclude Paths

```yaml
exclude-paths:
  - "vendor/**"
  - "test/fixtures/**"
```

## Advanced Options

### Versioning Strategy

Controls how Dependabot edits version constraints:

| Value | Behavior |
|---|---|
| `auto` | Default — increase for apps, widen for libraries |
| `increase` | Always increase minimum version |
| `increase-if-necessary` | Only change if current range excludes new version |
| `lockfile-only` | Only update lockfiles, ignore manifests |
| `widen` | Widen range to include both old and new versions |

### Rebase Strategy

```yaml
rebase-strategy: "disabled"  # stop auto-rebasing
```

Allow rebase over extra commits by including `[dependabot skip]` in commit messages.

### Open PR Limit

```yaml
open-pull-requests-limit: 10  # default is 5 for version, 10 for security
```

Set to `0` to disable version updates entirely.

### Private Registries

```yaml
registries:
  npm-private:
    type: npm-registry
    url: https://npm.example.com
    token: ${{secrets.NPM_TOKEN}}

updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - npm-private
```

## FAQ

**Can I have multiple `dependabot.yml` files?**
No. GitHub supports exactly one file at `.github/dependabot.yml`. Use multiple `updates` entries within that file for different ecosystems and directories.

**Does Dependabot support pnpm?**
Yes. Use `package-ecosystem: "npm"` — Dependabot detects `pnpm-lock.yaml` automatically.

**How do I reduce PR noise in a monorepo?**
Use `groups` to batch updates, `directories` with globs for coverage, and `group-by: dependency-name` for cross-directory grouping. Consider `monthly` or `quarterly` intervals for low-priority ecosystems.

**How do I handle dependencies outside the workspace?**
Create a separate ecosystem entry with its own `directory` pointing to that location.

## Pre-Commit Dependency Scanning via AI Coding Agents

For scanning code changes for vulnerable dependencies inside an AI coding agent before committing, the GitHub MCP Server's `dependabot` toolset can check your dependency additions against the GitHub Advisory Database and return structured results with affected packages, severity, and recommended fixed versions. For more thorough post-commit checks, it can also run the Dependabot CLI locally to diff dependency graphs before and after your changes.

Install the **Advanced Security plugin** which provides dedicated dependency scanning tools and the `/dependency-scanning` skill.

**GitHub Copilot CLI (shell):**
```bash
# Enable the dependabot toolset for the GitHub MCP Server
copilot --add-github-mcp-toolset dependabot
```

**GitHub Copilot CLI (inside `copilot`):**
```text
> /plugin install advanced-security@copilot-plugins
```

**Visual Studio Code:**
- Add `"X-MCP-Toolsets": "dependabot"` to your GitHub MCP Server headers, or pick **Dependabot** from the toolset selector in Copilot Chat
- Install the `advanced-security` plugin, then use `/dependency-scanning` in Copilot Chat

**Example prompt:**
> Scan the dependencies I added on this branch for known vulnerabilities and tell me which versions to upgrade to before I commit.

See: [Advanced Security Plugin — Dependency Scanning Skill](https://github.com/github/copilot-plugins/blob/main/plugins/advanced-security/skills/dependency-scanning/SKILL.md)

> Announced in [Dependency scanning with GitHub MCP Server is in public preview](https://github.blog/changelog/2026-05-05-dependency-scanning-with-github-mcp-server-is-in-public-preview/) (May 2026)

## Resources

- `references/dependabot-yml-reference.md` — Complete YAML options reference
- `references/pr-commands.md` — Full PR comment commands reference
- `references/example-configs.md` — Real-world configuration examples

版权与许可声明

MIT License

Copyright GitHub, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.