{"meta":{"title":"Dependabot 选项参考","intro":"所有可用于自定义 Dependabot 维护存储库方式的选项详细信息。","product":"安全性和代码质量","breadcrumbs":[{"href":"/zh/code-security","title":"安全性和代码质量"},{"href":"/zh/code-security/reference","title":"Reference"},{"href":"/zh/code-security/reference/supply-chain-security","title":"供应链安全"},{"href":"/zh/code-security/reference/supply-chain-security/dependabot-options-reference","title":"Dependabot 选项"}],"documentType":"article"},"body":"# Dependabot 选项参考\n\n所有可用于自定义 Dependabot 维护存储库方式的选项详细信息。\n\n本文提供有关`dependabot.yml`文件中可用配置选项的参考信息。 使用这些选项自定义 Dependabot 如何监视包生态系统、安排更新和创建拉取请求。 有关`dependabot.yml`文件及其工作原理的概述，请参阅[关于 dependabot.yml 文件](/zh/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file)。\n\n标有 图标的所有选项也会更改 Dependabot 创建安全更新拉取请求的方式，除非使用 `target-branch`。\n\n### 必需的密钥\n\n| Key | 位置 | 目的 |\n| ---------------------------------------------------------- | -------------------------- | ---------------------------------------------------------------------------------- |\n| `version` | 顶层 | |\n| Dependabot 要使用的配置语法。 始终：`2`。 | | |\n| `updates` | 顶层 | 定义每个 `package-ecosystem` 以进行更新的部分。 |\n| [`package-ecosystem`](#package-ecosystem-) | （位于 `updates` 下面） | 定义要更新的包管理器。 |\n| \\[ | | |\n| `directories` 或 `directory`]\\(#directories-or-directory--) | 在每个 `package-ecosystem` 项下 | 定义要更新的清单文件或其他定义文件的位置。 |\n| [`schedule.interval`](#schedule-) | 在每个 `package-ecosystem` 项下 | 定义是否查找版本更新：`daily`、、`weekly`、`monthly``quarterly`、`semiannually`、或。 `yearly``cron` |\n\n（可选）你还可以包含一个顶层 `registries` 密钥，以定义专用注册表的访问详情，请参阅[顶层 `registries` 密钥](#top-level-registries-key)。\n\n```yaml copy\n\n# Basic `dependabot.yml` file with\n# minimum configuration for two package managers\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates every day (weekdays)\n schedule:\n interval: \"daily\"\n\n # Enable version updates for Docker\n - package-ecosystem: \"docker\"\n # Look for a `Dockerfile` in the `root` directory\n directory: \"/\"\n # Check for updates once a week\n schedule:\n interval: \"weekly\"\n```\n\n要查看关于文件的实际示例，请参阅自己的配置文件。\n\n## `allow`\n\n用于精确定义要为包生态系统维护的依赖项。 通常与 [`ignore`](#ignore--) 选项配合使用。 有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated)”。\n\nDependabot 默认行为：\n\n* 清单中显式定义的所有依赖项都由版本更新保持最新。\n* 在具有易受攻击依赖项的锁文件中定义的所有依赖项都由安全更新更新。\n\n当`allow`被指定时，Dependabot使用以下过程：\n\n1. 检查所有明确**允许**的依赖项。\n2. 然后筛选掉所有被**忽略**的依赖项或版本。\n\n 如果某个依赖项同时匹配 `allow` 和 `ignore` 语句，则会被**忽略**。\n\n| 参数 | 目的 |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | 允许名称匹配的依赖项进行更新，可选使用 `*` 匹配零个或多个字符。 |\n| `dependency-type` | 允许特定类型的依赖项进行更新。 |\n| | |\n| `update-types` | 允许更新一个或多个语义版本控制级别。 支持的值：`version-update:semver-patch`、`version-update:semver-minor`和 `version-update:semver-major`。 |\n| | |\n\n### `dependency-name`（`allow`）\n\n对于大多数包管理器，应定义一个值，使其与锁定文件或清单文件中指定的依赖项名称匹配。 少数系统有更复杂的要求。\n\n| 程序包管理器 | 所需格式 | Example |\n| -------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------- |\n| Gradle 和 Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| 用于映像标签的 Docker | 存储库的全名 | 对于 `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` 的映像标签，请使用 `base/foo/bar/ruby`。 |\n\n### `dependency-type`（`allow`）\n\n| 依赖项类型 | 支持的包管理器 | 允许更新 |\n| ------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------------------------- |\n| `direct` | All | 所有明确定义的依赖项。 |\n| `indirect` | | |\n| `bundler`、`pip`、`composer`、`cargo`、`gomod`、`uv` | 直接依赖项的依赖项（也称为子依赖项或传递依赖项）。 | |\n| `all` | All | 所有明确定义的依赖项。 对于 `bundler`、`pip`、`composer`、`cargo`、`gomod`、`uv`，还包括直接依赖项的依赖项。 |\n| `production` | | |\n| `bundler`、`composer`、`mix`、`maven`、`npm`、`pip`、`uv`（并非所有都是经理） | 仅适用于包管理器定义为生产依赖项的依赖项。 | |\n| `development` | | |\n| `bundler`、`composer`、`mix`、`maven`、`npm`、`pip`、`uv`（并非所有都是经理） | 仅适用于包管理器定义为开发依赖项的依赖项。 | |\n\n### `update-types`（`allow`）\n\n`update-types` 仅影响 *版本* 更新，而不会影响 *安全更新*。\n\n指定要允许的语义版本（SemVer）。\n\nSemVer 是定义软件包版本的公认标准，格式为 `x.y.z`。\nDependabot 假定以这种形式的版本始终为 `major.minor.patch`。 该值 `update-types` 是一个或多个字符串的列表。\n\n* 使用 `version-update:semver-patch` 以允许修补程序发布。\n* 使用 `version-update:semver-minor` 允许小版本发布。\n* 使用 `version-update:semver-major` 以允许主要版本发布。\n\n如果 `update-types` 从 `allow` 规则中省略，则允许该规则使用所有更新类型。\n\n可以结合`update-types``dependency-name`或`dependency-type`进一步缩小允许的更新范围。 有关如何合并这些选项的示例，请参阅 [控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-semantic-versioning-levels-for-updates)。\n\n## `assignees`\n\n为针对包生态系统提出的所有所有拉取请求指定单个代理人。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* 创建的拉取请求不含任何代理人。\n\n当定义 `assignees` 时：\n\n* 所有版本更新的拉取请求都由指定的指派者创建。\n* 所有安全更新拉取请求均使用选定的受理人创建，除非 `target-branch` 定义了对非默认分支的更新。\n\n代理人必须具有对仓库的写入访问权限。 对于组织拥有的存储库，具有读取权限的组织成员也是有效的代理人。\n\n## `commit-message`\n\n定义提交消息的格式。 由于拉取请求的标题基于提交消息编写，因此此设置也会影响拉取请求的标题。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* 提交消息遵循与存储库中检测到的模式类似的模式。\n\n当定义 `commit-message` 时：\n\n* 所有提交消息都遵循定义的模式。\n* 所有提交消息都遵循定义的模式，除非 `target-branch` 定义对非默认分支的更新。\n\n| 参数 | 目的 |\n| -------------------- | ----------------------------------- |\n| `prefix` | 为所有提交消息和拉取请求标题定义前缀。 |\n| `prefix-development` | 在受支持的系统上，为更新“开发依赖项组”中依赖项的提交定义不同的前缀。 |\n| `include` | 在提交信息前缀后面添加附加信息。 |\n\n> \\[!TIP]\n> 当为分组更新提出拉取请求时，分支名称和拉取请求标题由组 `IDENTIFIER` 定义，请参阅 [`groups`](#groups--)。\n\n### `prefix`\n\n* 用于所有提交消息，除非还定义了 `prefix-development`。\n* 值最多可包含 50 个字符。\n* Dependabot 当值以字母、数字、右括号或右括号结尾时，在添加主提交消息之前，在前缀后面插入冒号。\n* 以空格字符结束该值，可避免添加冒号。\n\n### `prefix-development`\n\n支持：`bundler`、、`composer`、`mix`、`maven``npm`、、 `pip`和`uv`。\n\n* 仅用于更新“开发依赖项组”中依赖项的提交消息。\n* 否则，该参数的行为与 `prefix` 参数完全相同。\n\n### `include`\n\n* 仅支持值 `scope`\n* 当定义时，任何前缀将后跟提交中更新的依赖项类型：`deps` 或 `deps-dev`。\n\n## `cooldown`\n\n定义依赖项更新的冷却期，允许更新延迟指定天数\\*\\*\\*\\*。 此选项 `cooldown` 仅适用于 *版本* 更新，而不适用于 *安全更新* 。\n\n此功能使用户能够自定义生成新版本更新的频率 Dependabot ，从而更好地控制更新频率。 有关示例，请参阅“[优化 Dependabot 版本更新的拉取请求创建](/zh/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#setting-up-a-cooldown-period-for-dependency-updates)”。\n\nDependabot 默认行为：\n\n* 根据通过 `schedule.interval` 定义的计划检查更新。\n* 将 **默认冷却期 3 天** 应用于版本更新，即使 `cooldown` 未配置也是如此。 新版本在发布后 3 天内不会被纳入版本更新考虑。\n **此默认冷却不适用于安全更新。**\n\n您可以配置 `cooldown` 选项，以自定义这些默认冷却时间，并控制这些冷却时间应用于哪些依赖项。 当定义 **`cooldown`** 时：\n\n1. Dependabot 根据定义的 `schedule.interval` 设置检查更新。\n2. Dependabot 检查是否有任何冷却设置。\n3. 如果依赖项的新版本在其冷却期内， Dependabot 则跳过更新该依赖项的版本。\n4. 没有冷却期的依赖项，或已过冷却期的依赖项，会根据已配置的 `versioning-strategy` 设置更新至最新版本。\n5. 在依赖项的冷却结束之后， Dependabot 按照定义的 `dependabot.yml`标准更新策略恢复更新依赖项。\n\n### **`cooldown` 的配置**\n\n可以使用以下选项指定冷却的持续时间。\n\n| 参数 | Description |\n| ------------------- | ---------------------------------------------------------- |\n| `default-days` | 没有特定规则**的依赖项的默认冷却期**（可选）。 如果未指定， Dependabot 则应用默认冷却时间 3 天。 |\n| `semver-major-days` | 主要版本更新的冷却期（可选，仅适用于支持 SemVer 的包管理器）\\*\\*\\*\\*。 |\n| `semver-minor-days` | 次要版本更新的冷却期（可选，仅适用于支持 SemVer 的包管理器）\\*\\*\\*\\*。 |\n| `semver-patch-days` | 补丁版本更新的冷却期（可选，仅适用于支持 SemVer 的包管理器）\\*\\*\\*\\*。 |\n| `include` | 需要应用冷却期的依赖项的列表（最多 150 项）\\*\\*\\*\\*\\*\\*\\*\\*。 支持使用通配符 (`*`)。 |\n| `exclude` | 排除在冷却期之外的依赖项列表（最多 150 项）\\*\\*\\*\\*\\*\\*\\*\\*。 支持使用通配符 (`*`)。 |\n\n下表显示了支持 `cooldown`包管理器。 对于列出的所有包管理器，均支持 `default-days` 选项；而 `semver-major-days`、`semver-minor-days` 和 `semver-patch-days` 仅在标明支持的情况下才受支持。\n\n| 程序包管理器 | 支持的默认天数 | 支持的 SemVer 递增天数 |\n| -------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |\n| | | |\n| 巴泽尔 | | |\n| | | |\n| Bundler | | |\n| Bun | | |\n| Cargo | | |\n| Composer | | |\n| | | |\n| Conda | | |\n| | | |\n| | | |\n| Deno | | |\n| | | |\n| DevContainer | | |\n| Docker | | |\n| Docker Compose | | |\n| Dotnet SDK | | |\n| Elm | | |\n| GitHub Actions | | |\n| Gitsubmodule | | |\n| Gomod（Go 模板） | | |\n| Gradle | | |\n| Helm | | |\n| 十六进制 | | |\n| | | |\n| Julia | | |\n| | | |\n| Maven | | |\n| | | |\n| Nix 碎片 | | |\n| | | |\n| NPM 和 Yarn | | |\n| NuGet | | |\n| | | |\n| OpenTofu | | |\n| | | |\n| Pip | | |\n| | | |\n| pre-commit | | |\n| | | |\n| Pub | | |\n| | | |\n| Rust 工具链 | | |\n| | | |\n| | | |\n| sbt | | |\n| | | |\n| Swift | | |\n| Terraform | | |\n| UV | | |\n| | | |\n| vcpkg | | |\n| | | |\n\n> \\[!NOTE]\n>\n> * 如果未定义 `semver-major-days`、`semver-minor-days` 或 `semver-patch-days`，则 `default-days` 设置优先于基于冷却期的更新。\n> *\n\n`exclude` 列表始终优先于 `include` 列表。 如果在两个列表同时指定了某个依赖项，则该依赖项将排除在冷却期之外，并将立即更新\\*\\*\\*\\*。\n\n## `directories` 或 `directory`\n\n**必需选项**。 用于定义每个包管理器的包清单位置（例如 *package.json* 或 *Gemfile*）。 如果没有此信息 Dependabot ，则无法为版本更新创建拉取请求。 有关示例，请参阅[针对清单文件定义多个位置](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-multiple-locations-for-manifest-files)。\n\n* 使用 `directory` 定义单个清单目录。\n\n* 使用 `directories` 定义多个清单目录的列表。\n\n* 为大多数包管理器定义相对于仓库根目录的目录。\n\n* 对于 GitHub Actions，请使用值 `/`。\n Dependabot 将搜索 `/.github/workflows` 目录以及 `action.yml/action.yaml` 根目录中的文件。\n\n如果需要在配置文件中使用多个块来定义生态系统的单个目标分支的更新，必须确保所有值都是唯一的，并且定义的目录没有重叠。\n\n> \\[!NOTE]\n> `directories` 键支持通配和通配符 `*`。 `directory` 键不支持这些功能。\n\n## `enable-beta-ecosystems`\n\n当前未使用。\n\n## `groups`\n\n定义规则以创建包管理器管理的一组或多组依赖项，以将更新分组到针对性更弱的拉取请求中。 有关示例，请参阅“[优化 Dependabot 版本更新的拉取请求创建](/zh/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates)”。\n\nDependabot 默认行为：\n\n* 针对版本更新和安全更新，为每个需要更新到较新版本的依赖项打开单个拉取请求。\n\n当使用 `groups` 定义规则时：\n\n* 所有匹配某一规则的依赖项更新会合并到同一个拉取请求中。\n* 如果依赖项与多个规则匹配，则它包含在匹配的第一个组中。\n* 所有与规则不匹配的过时依赖项将在单独的拉取请求中更新。\n\n| 参数 | 目的 |\n| ------------------ | ---------------------------------------------------------------------- |\n| `IDENTIFIER` | 定义组的标识符，用于分支名称和拉取请求标题。 该名称必须以字母开头，可包含字母、竖线 `\\|`、字下线 `_` 或短划线 `-`。 |\n| `applies-to` | 指定组适用的更新类型。 未定义时，默认为版本更新。 支持的值：`version-updates` 或 `security-updates`。 |\n| `dependency-type` | 将组限制为一个类型。 支持的值：`development` 或 `production`。 |\n| `exclude-patterns` | 定义一个或多个模式，以从组中排除依赖项。 |\n| | |\n| `group-by` | 对多个目录中的更新进行分组。 支持的值：`dependency-name`。 |\n| | |\n| `patterns` | 定义一个或多个模式，以包含名称匹配的依赖项。 |\n| `update-types` | 将组限制为一个或多个语义化版本控制级别。 支持的值：`minor`、`patch`和 `major`。 |\n\n### `dependency-type`（`groups`）\n\n受以下类型支持：`bundler`、`composer`、`mix`、`maven`、`npm` 和 `pip`。\n\n默认情况下，一个组将包含所有类型的依赖项。\n\n* 使用 `development` 以仅包含“开发依赖项组”中的依赖项。\n* 使用 `production` 以仅包含“生产依赖项组”中的依赖项。\n\n### `group-by`（`groups`）\n\n请使用 `groups..group-by` 指定如何在 monorepo 的多个目录中对 Dependabot 进行更新分组。\n\n* **类型：** 字符串\n* **接受的值：**`dependency-name`\n* **适用于：** 指定了多个目录的配置\n\n设置为 `dependency-name`时， Dependabot 将为所有指定目录的每个依赖项更新创建单个拉取请求，而不是为每个目录创建单独的拉取请求。\n\n**跨目录分组的限制**\n\n使用 `group-by: dependency-name` 时：\n\n* 所有目录都必须使用相同的包生态系统（例如，全部 `npm` 或全部 `bundler`）\n* **仅适用于版本更新**\n* 如果目录对依赖项具有不兼容的版本约束， Dependabot 将创建单独的拉取请求\n\n有关`group-by`用法的示例，请参阅[优化 Dependabot 版本更新的拉取请求创建](/zh/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#grouping-updates-across-directories-in-a-monorepo)。\n\n### `patterns` 和 `exclude-patterns`（`groups`）\n\n这两个选项均支持使用 `*` 作为通配符来定义依赖项名称匹配。 如果某个依赖项同时匹配包含模式和排除模式，则会从组中排除。\n\n### `update-types`（`groups`）\n\n默认情况下，组将包含所有语义化版本 (SemVer) 的更新。 SemVer 是定义软件包版本的公认标准，格式为 `x.y.z`。 Dependabot 假定此格式的版本始终为 `major.minor.patch`。\n\n* 使用 `patch` 以包含补丁发布。\n* 使用 `minor` 以包含次要发布。\n* 使用 `major` 以包含主要发布。\n\n有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore)”。\n\n## `ignore`\n\n与 [`allow`](#allow--) 选项配合使用，以精确定义要为包生态系统维护的依赖项。\nDependabot 检查所有允许的依赖项，然后筛选掉任何忽略的依赖项或版本。 因此，同时被允许和忽略规则匹配的依赖项将被忽略。 有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-dependencies)”。\n\nDependabot 默认行为：\n\n* 清单中显式定义的所有依赖项都由版本更新保持最新。\n* 在具有易受攻击依赖项的锁文件中定义的所有依赖项都由安全更新更新。\n\n使用`ignore`时Dependabot使用以下过程：\n\n1. 检查所有明确**允许**的依赖项。\n2. 然后筛选掉所有被**忽略**的依赖项或版本。\n\n 如果某个依赖项同时匹配 `allow` 和 `ignore` 语句，则会被**忽略**。\n\n| 参数 | 目的 |\n| ----------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | 忽略名称匹配的依赖项的更新，可选使用 `*` 匹配零个或多个字符。 |\n| `versions` | 忽略特定版本或版本范围。 |\n| `update-types` | 忽略一个或多个语义化版本控制级别的更新。 支持的值：`version-update:semver-patch`、`version-update:semver-minor`和 `version-update:semver-major`。 |\n\n### `dependency-name`（`ignore`）\n\n对于大多数包管理器，应定义一个值，使其与锁定文件或清单文件中指定的依赖项名称匹配。 少数系统有更复杂的要求。\n\n| 程序包管理器 | 所需格式 | Example |\n| -------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------- |\n| Gradle 和 Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| 用于映像标签的 Docker | 存储库的全名 | 对于 `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` 的映像标签，请使用 `base/foo/bar/ruby`。 |\n\n### `versions`（`ignore`）\n\n用于忽略特定版本或版本范围。 如果要定义范围，请使用包管理器的标准模式。 例如：\n\n* npm：使用 `^1.0.0` \n* Bundler：使用 `~> 2.0`\n* Docker：使用 Bundler 版本语法\n* NuGet：使用 `7.*`\n* Maven：使用 `[1.4,)`\n\n有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-versions-or-ranges-of-versions)”。\n\n### `update-types`（`ignore`）\n\n指定要忽略的语义化版本 (SemVer)。 SemVer 是定义软件包版本的公认标准，格式为 `x.y.z`。\nDependabot 假定以这种形式的版本始终为 `major.minor.patch`。\n\n* 使用 `version-update:semver-patch` 以包含补丁发布。\n* 使用 `version-update:semver-minor` 以包含次要发布。\n* 使用 `version-update:semver-major` 以包含主要发布。\n\n## `insecure-external-code-execution`\n\n受以下类型支持：`bundler`、`mix` 和 `pip`。\n\n允许 Dependabot 在更新期间在清单中执行外部代码。 有关示例，请参阅[允许外部代码执行](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#allowing-external-code-execution)。\n\nDependabot 默认行为：\n\n* 授予 Dependabot 对一个或多个注册表的访问权限时，会自动禁用外部代码执行，以保护代码免受包泄露的影响。\n* 若无法执行代码，版本更新可能会失败。\n\n当你允许 `insecure-external-code-execution` 时：\n\n* Dependabot 将在清单中执行代码作为版本更新过程的一部分。\n* 该代码仅能访问与该`updates`设置关联的注册表中的包管理器。 不允许访问顶级 `registries` 配置中定义的任何注册表。\n* 这应能使更新成功，但也可能允许受损包窃取凭据或访问已配置的注册表。\n\n支持的值：`allow`。\n\n## `labels`\n\n为针对包管理器提出的所有拉取请求指定自定义标签。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* 所有拉取请求均带有 `dependencies` 标签。\n* 如果定义了多个包管理器，每个拉取请求会额外添加一个生态系统或语言标签。 例如：`java` 用于 Gradle 更新，`submodules` 用于 Git 子模块更新。\n* 如果存储库中存在语义版本（SemVer）标签，它们将自动应用以指示版本更新的类型（`major`或`minor``patch`）。\n* Dependabot 根据需要在存储库中自动创建这些默认标签。\n\n当定义 `labels` 时：\n\n* 指定的标签将替代默认标签。\n* 除定义的任何自定义标签外，SemVer 标签（如果存在于存储库中）仍将应用。\n* 如果其中任何标签未在仓库中定义，将被忽略。\n* 可使用 `labels: [ ]` 禁用所有标签（包括默认标签）。\n\n设置此选项还会影响此包管理器的清单文件安全更新拉取请求，除非使用 `target-branch` 检查非默认分支上的版本更新。\n\n## `milestone`\n\n将针对包管理器提出的所有拉取请求与里程碑关联。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* 不使用任何里程碑。\n\n当定义 `milestone` 时：\n\n* 该包管理器的所有拉取请求都会添加到该里程碑。\n\n支持的值：里程碑的数字标识符。\n\n> \\[!TIP]\n> 如果查看里程碑，则 `milestone` 之后的页面 URL 的最后一部分是标识符。 有关示例 `https://github.com///milestone/3`，请参阅 [查看里程碑的进度](/zh/issues/using-labels-and-milestones-to-track-work/viewing-your-milestones-progress)。\n\n## `multi-ecosystem-groups`\n\n定义跨多个包生态系统的组，以获取单个 Dependabot 拉取请求，更新所有受支持的包生态系统。 此方法有助于减少收到的拉取请求数 Dependabot 并简化依赖项更新工作流。\n\nDependabot 默认行为：\n\n* 为具有依赖项更新的每个包生态系统创建单独的拉取请求。\n\n使用 `multi-ecosystem-groups` 时：\n\n* 同一组中跨多个包生态系统的更新会被合并到一个拉取请求中。\n* 各组拥有独立的计划，可以继承或替代单个生态系统设置。\n\n### `multi-ecosystem-group`\n\n要将单个包生态系统分配到多生态系统组中，可以在 `multi-ecosystem-group` 配置中使用 `updates` 参数。\n\n> \\[!IMPORTANT]\n> 多生态系统更新需要特定的配置模式，并且具有唯一的参数合并行为。 有关完整的设置说明、配置示例和详细参数参考，请参阅“AUTOTITLE”[](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates)。\n\n```yaml copy\n# Basic `dependabot.yml` file defining a multi-ecosystem-group\nversion: 2\n\nmulti-ecosystem-groups:\n infrastructure:\n schedule:\n interval: \"weekly\"\n\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/\"\n patterns: [\"nginx\", \"redis\"]\n multi-ecosystem-group: \"infrastructure\"\n\n - package-ecosystem: \"terraform\"\n directory: \"/\"\n patterns: [\"aws\"]\n multi-ecosystem-group: \"infrastructure\"\n```\n\n## `open-pull-requests-limit`\n\n更改任何时候可打开的版本更新拉取请求的最大数量限制。\n\nDependabot 默认行为：\n\n* 如果有五个版本更新拉取请求处于打开状态，在其中部分请求合并或关闭前，不会再提出新的拉取请求。\n\n> \\[!NOTE]\n> *安全更新* 拉取请求不受此限制的约束，不计入此限制。 安全更新的开放拉取请求数没有限制。\n\n当定义 `open-pull-requests-limit` 时：\n\n* Dependabot 打开的拉取请求数量最多为定义的整数值。 可以设置一个大值，以有效取消打开的拉取请求限制。\n* 可以通过将此选项设置为零来暂时禁用包管理器的版本更新，请参阅 [“禁用 Dependabot version updates](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#disabling-dependabot-version-updates)”。\n\n## `package-ecosystem`\n\n\n\n**必需选项。** 为每个希望 `package-ecosystem` 监视新版本的包管理器定义一个 Dependabot 元素。 存储库还必须包含每个包管理器的依赖项清单或锁定文件，请参阅[示例 `dependabot.yml` 文件](/zh/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#example-dependabotyml-file)。\n\n| 程序包管理器 | YAML 值 | 支持的版本 |\n| -------------- | ---------------- | :---------------: |\n| | | |\n| 巴泽尔 | `bazel` | v7、v8、v9 |\n| | | |\n| Bun | `bun` | >=v1.1.39 |\n| Bundler | `bundler` | v2 |\n| Cargo | `cargo` | v1 |\n| Composer | `composer` | v2 |\n| | | |\n| Conda | `conda` | 不適用 |\n| | | |\n| | | |\n| Deno | `deno` | >=v2 |\n| | | |\n| 开发容器 | `devcontainers` | 不適用 |\n| Docker | `docker` | v1 |\n| Docker Compose | `docker-compose` | V2 和 V3 |\n| .NET SDK | `dotnet-sdk` | >=.NET Core 3.1 |\n| | | |\n| Helm 图表 | `helm` | v3 |\n| | | |\n| Hex | `mix` | v1 |\n| | | |\n| Julia | `julia` | >=v1.10 |\n| | | |\n| elm-package | `elm` | v0.19 |\n| git 子模块 | `gitsubmodule` | 不適用 |\n| GitHub Actions | `github-actions` | 不適用 |\n| Go 模块 | `gomod` | v1 |\n| Gradle | `gradle` | 不適用 |\n| Maven | `maven` | 不適用 |\n| | | |\n| Nix 碎片 | `nix` | 不適用 |\n| | | |\n| npm | `npm` | v7、v8、v9、v10、v11 |\n| NuGet | `nuget` | <=6.12.0 |\n| | | |\n| OpenTofu | `opentofu` | 不適用 |\n| | | |\n| pip | `pip` | 26.1.1 |\n| pip-compile | `pip` | 7.5.3 |\n| pipenv | `pip` | 2024.4.1 |\n| pnpm | `npm` | v7、v8、v9、v10 |\n| poetry | `pip` | v2 |\n| | | |\n| pre-commit | `pre-commit` | 不適用 |\n| | | |\n| 酒馆 | `pub` | v2 |\n| | | |\n| Rust 工具链 | `rust-toolchain` | 不適用 |\n| | | |\n| | | |\n| sbt | `sbt` | 不適用 |\n| | | |\n| Swift | `swift` | v5、v6 |\n| Terraform | `terraform` | >= 0.13，<= 1.15.x |\n| uv | `uv` | v0.11 |\n| | | |\n| vcpkg | `vcpkg` | 不適用 |\n| | | |\n| yarn | `npm` | v1、v2、v3、v4 |\n\n## `pull-request-branch-name`\n\n配置 Dependabot 生成拉取请求分支名称的方式。 可以自定义分隔符、前缀、长度、大小写、字分隔符并提供自定义模板。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* 生成以下格式的分支名称：`dependabot/PACKAGE-MANAGER/DEPENDENCY`\n\n| 参数 | 类型 | 默认 | Description |\n| --------------------------------------- | --------------- | -------------- | ---------------------------- |\n| [`separator`](#separator) | String | `\"/\"` | 分支名称段之间使用的字符。 |\n| [`prefix`](#prefix) | 字符串 （最大 50 个字符） | `\"dependabot\"` | 前面追加到分支名称的字符串。 |\n| [`max-length`](#max-length) | 整数 （20–244） | `100` | 分支名称的最大字符长度。 |\n| [`word-separator`](#word-separator) | String | 未设置 | 用于替换分支名称中前缀后内容里的下划线的字符（`_`）。 |\n| [`branch-name-case`](#branch-name-case) | String | 未设置 | 将大小写转换应用于前缀后面的分支名称内容。 |\n| [`template`](#template) | 字符串（最多 200 个字符） | 未设置 | 使用占位符的自定义格式模板。 |\n\n所有选项都是可组合的。 当 `template` 与简单选项一起设置时，处理顺序如下：\n\n1. 模板渲染（占位符替换）\n2. 分隔符替换（`/` 替换为已配置的分隔符）\n3. 单词分隔符替换（将 `_` 替换为已配置的单词分隔符）\n4. 前缀后应用于内容的事例转换\n5. 最大长度截断\n\n### `separator`\n\n指定在分支名称各段之间用来替代 `/` 的字符。\n\n支持的值：`\"-\"`、`_`、`/`\n\n例如，使用 `separator: \"-\"` 时：`dependabot/npm_and_yarn/lodash-4.17.21` 变为 `dependabot-npm_and_yarn-lodash-4.17.21`。\n\n> \\[!TIP]\n> 连字符必须转义，以免被解释为开始空 YAML 列表。\n\n### `prefix`\n\n指定在分支名称的开头使用的自定义字符串，而不是默认值 `dependabot`。\n\n该值最多可为 50 个字符。\n\n例如，使用 `prefix: \"deps\"` 时：`dependabot/npm_and_yarn/lodash-4.17.21` 变为 `deps/npm_and_yarn/lodash-4.17.21`。\n\n### `max-length`\n\n为生成的分支名称设置允许的最大长度。\n\n* 最小值： `20`.\n* 最大值： `244`.\n* 默认值：`100`。\n* 当分支名称超出此限制时，将截断该名称，并追加哈希后缀以保留唯一性。\n\n例如，使用 `max-length: 40` 时，像 `dependabot/npm_and_yarn/some-long-dependency-name-1.0.0` 这样的分支名称会被截断为 40 个字符，并带有哈希后缀。\n\n### `word-separator`\n\n指定一个字符，用于替换前缀之后的所有分支名称内容中的下划线（`_`），包括包管理器名称、依赖项名称、组名称和目录路径。\n\n例如，使用 `word-separator: \"-\"`：\n\n* `npm_and_yarn` → `npm-and-yarn`\n* `front_end_dir` → `front-end-dir`\n\n### `branch-name-case`\n\n将大小写转换应用于前缀后面的分支名称内容。\n\n支持的值：`\"lowercase\"`、`\"uppercase\"`\n\n例如，使用 `branch-name-case: \"lowercase\"` 时：`dependabot/npm_and_yarn/Lodash-4.17.21` 变为 `dependabot/npm_and_yarn/lodash-4.17.21`。\n\n### `template`\n\n使用占位符定义自定义分支名称格式。 该模板可让你完全控制生成的分支名称的结构。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\n可用的占位符取决于更新策略：\n\n| 占位符 | 独奏更新 | 分组更新 | 多生态系统组 | Description |\n| ------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ----------------------------- |\n| `{prefix}` | | | | 配置的前缀（默认值 `dependabot`）。 |\n| `{package_manager}` | | | | 包生态系统标识符（例如 `npm_and_yarn`）。 |\n| `{directory}` | | | | 依赖文件目录。 |\n| `{target_branch}` | | | | 如果已配置，则为目标分支。 |\n| `{dependency}` | | | | 依赖项名称。 |\n| `{version}` | | | | 新版本或参考编号。 |\n| `{group_name}` | | | | 配置的组名称。 |\n| `{name}` | | | | 策略适当的名称：单独更新的依赖项和版本、分组更新的组名称。 |\n\n模板验证规则：\n\n* 所有占位符都必须能被识别，并且是当前使用的更新策略所允许的。\n* 花括号必须格式正确（不能有未闭合的 `{` 或 `}`）。\n* 在多生态系统组模板中使用 `{package_manager}` 会引发验证错误，因为没有单个包管理器适用。\n* 呈现的分支名称必须是有效的 Git 引用名称。 不允许使用空格、`~`、`^`、`:`、`?`、`*`、`[` 和 `\\` 等字符，类似 `..` 或 `@{` 的序列也会被拒绝。\n* 对于分组更新和多生态系统更新，系统会自动在分支名称后附加一个 10 个字符的摘要值，以保证其唯一性。 这不是用户控制的。\n\n## `rebase-strategy`\n\n禁用 Dependabot 发起的拉取请求的自动变基。\n\nDependabot 默认行为是在 Dependabot 检测到版本或安全更新拉取请求有任何更改时，对打开的拉取请求执行变基。\nDependabot 会在以下情况下检查更改：\n\n* 你的计划运行以检查版本更新。\n* 您重新打开了已关闭的Dependabot拉取请求。\n* 你在 `target-branch` 配置文件中更改的 Dependabot 值，请参阅[`target-branch`](#target-branch-)。\n* 最近推送到目标分支后，Dependabot 拉取请求出现冲突。\n\n当 `rebase-strategy` 设置为 `disabled` 时，Dependabot 将停止对拉取请求执行变基。\n\n> \\[!NOTE]\n> 禁用变基**前**已打开的拉取请求将继续进行变基，直至打开后 30 天。 这会影响所有与目标分支存在冲突的拉取请求以及所有版本更新拉取请求。\n\n## `registries`\n\n配置对专用包注册表的访问以允许 Dependabot 更新更广泛的依赖项，请参阅 [为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries) 和 [针对 Dependabot 的专用注册表配置指南](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries)。\n\n`dependabot.yml` 文件中有 2 个位置可以使用 `registries` 密钥：\n\n1. 在顶层定义要使用的专用注册表及其访问信息，请参阅 [为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries)。\n2. 在 `updates` 块中，可指定每个包管理器应使用的专用注册表。\n\nDependabot 默认行为是仅引发拉取请求，以更新存储在可公开访问的注册表中的依赖项。\n\nDependabot当配置文件具有顶级`registries`部分（定义对一个或多个专用注册表的访问权限）时，可以将每个`package-ecosystem`注册表配置为使用其中一个或多个专用注册表。\n\n当为包管理器定义 `registries` 时：\n\n* 会检查为该包管理器指定的每个专用注册表是否有版本更新和安全更新。\n* Dependabot 使用顶级 `registries` 部分中定义的访问详细信息。\n\n支持的值：`REGISTRY_NAME` 或 `\"*\"`\n\n## `schedule`\n\n**必需选项。** 通过 `interval` 参数定义你配置的每个包管理器检查新版本的频率。 （可选）对于每日和每周间隔，你可自定义 Dependabot 检查更新的时间。 有关示例，请参阅“[优化 Dependabot 版本更新的拉取请求创建](/zh/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates)”。\n\n| 参数 | 目的 |\n| ------------------------ | ---------------------------- |\n| [`interval`](#interval) | |\n| **必填。** 为Dependabot定义频率。 | |\n| [`day`](#day) | 为**每周**间隔指定运行日期。 |\n| [`time`](#time) | 指定运行时间。 |\n| | |\n| [`cronjob`](#cronjob) | 如果间隔类型为 `cron`，则定义 cron 表达式。 |\n| | |\n| [`timezone`](#timezone) | 指定 `time` 值的时区。 |\n\n### `interval`\n\n支持的值：`daily`、`weekly`、`monthly`、`quarterly`、`semiannually`、`yearly` 或 `cron`\n\n每个包管理器必须定义计划间隔\\*\\*\\*\\*。\n\n* 使用 `daily` 在每个工作日（周一至周五）运行。\n* 使用 `weekly` 每周运行一次，默认在周一。\n* 使用 `monthly` 在每月的第一天运行。\n* 使用 `quarterly` 在每个季度（1 月、4 月、7 月和 10 月）的第一天运行。\n* 使用 `semiannually` 在 1 月和 7 月的第一天每隔六个月运行一次。\n* 使用 `yearly` 在 1 月的第一天运行。\n* 对基于 cron 表达式的计划选项使用 `cron` 。 请参阅 [`cronjob`](#cronjob)。\n\n> \\[!NOTE]\n> 支持的值 `quarterly`、`semiannually` 和 `yearly` 仅在版本 3.19 的 GitHub Enterprise Server 中可用。\n\n默认情况下， Dependabot 随机分配一个时间以应用配置文件中的所有更新。 可以使用 `time` 和 `timezone` 参数为所有间隔设置特定的运行时。\\\n如果使用间隔 `cron` ，可以使用表达式定义更新时间 `cronjob` 。\n\n### `day`\n\n支持的值：`monday`、`tuesday`、`wednesday`、`thursday`、`friday`、`saturday` 或 `sunday`\n\n（可选）为包管理器在一周的特定日期运行**每周**更新。\n\n### `time`\n\n格式：`hh:mm`\n\n（可选）为包管理器在一天的特定时间运行所有更新。 默认情况下，时间解释为 UTC。\n\n### `cronjob`\n\n支持的值：采用 cron 语法的有效 cron 表达式或自然语言表达式。\n\n计划任务语法有五个字段，中间用空格分隔，每个字段代表一个时间单位。\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\n示例：`0 9 * * *`、`every day at 5pm`\n\n`0 9 * * *` 等同于“每天上午 9 点”。\n`every day at 5pm` 等效于 `0 17 * * *`。\n\n> \\[!NOTE]\n>\n> * 必须在参数中 [`timezone`](#timezone) 指定时区，而不是在 `cronjob`.\n> * 使用 `cronjob` 间隔需要 `cron` 类型计划。\n\n```yaml copy\n\n# Basic `dependabot.yml` file for cronjob\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates based on `cronjob` value\n schedule:\n interval: \"cron\"\n cronjob: \"0 9 * * *\"\n```\n\n### `timezone`\n\n指定 `time` 值的时区。 默认时区为 `UTC`。\n\n时区标识符必须与 [iana](https://www.iana.org/time-zones) 维护的数据库中的时区匹配，请参阅 [tz 数据库时区列表](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)。\n\n## `target-branch`\n\n定义用于检查版本更新并作为版本更新拉取请求目标的特定分支。 有关示例，请参阅“[自定义 Dependabot 拉取请求以适应你的流程](/zh/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)”。\n\nDependabot 默认行为：\n\n* Dependabot 使用存储库的默认分支，请参阅 [“关于默认分支](/zh/pull-requests/reference/branches#about-the-default-branch)”。\n\n当定义 `target-branch` 时：\n\n* 仅检查目标分支上的清单文件是否有版本更新。\n* 会打开针对指定分支的版本更新的所有拉取请求。\n* 为此 `package-ecosystem` 定义的选项不再适用于安全更新，因为安全更新始终使用仓库的默认分支。\n\n## `exclude-paths`\n\n用于指定在扫描清单和依赖项时应忽略的目录和文件 Dependabot 的路径。 当你希望阻止特定位置（例如测试资源、供应商代码或特定文件）的依赖项更新时，此选项非常实用。\n\nDependabot 默认行为：\n\n* 指定 `directory` 中的所有目录和文件均会包括在更新扫描中，除非通过此选项将其排除。\n\n当定义 `exclude-paths` 时：\n\n* 在针对给定 `package-ecosystem` 条目的更新扫描期间，所有与指定路径匹配的文件和目录都会被忽略。\n\n| 参数 | 目的 |\n| --------------- | --------------------- |\n| `exclude-paths` | 要忽略的文件或目录的 glob 模式列表。 |\n\n支持 Glob 模式，例如用于递归匹配的 `**` 和单段通配符匹配的 `*`。 模式路径相对于更新配置中指定的 `directory`。 每个生态系统都可以拥有其自己的 `exclude-paths` 设置。\n\n### Example\n\n```yaml copy\nversion: 2\nupdates:\n - package-ecosystem: \"npm\"\n directory: \"/\"\n schedule:\n interval: \"daily\"\n exclude-paths:\n - \"src/test/assets\"\n - \"vendor/**\"\n - \"src/*.js\"\n - \"src/test/helper.js\"\n\n# Sample patterns that can be used-\n\n# Pattern: docs/*.json\n# Matches: docs/foo.json, docs/bar.json\n\n# Pattern: *.lock\n# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)\n\n# Pattern: test/**\n# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt\n\n# Pattern: config/settings.yml\n# Matches: config/settings.yml\n\n# Pattern: **/*.md\n# Matches: README.md, docs/guide.md, any/depth/file.md\n\n# Pattern: src/*\n# Matches: src/main.rb, src/app.js\n# Does NOT match: src/utils/helper.rb\n\n# Pattern: hidden/.*\n# Matches: hidden/.env, hidden/.secret\n```\n\n在此示例中，扫描更新时将忽略Dependabot目录、`src/test/assets`目录下的所有文件、直接位于`vendor/`下的所有 JavaScript 文件，以及特定文件`src/`和`src/test/helper.js`。\n\n## `vendor`\n\n受以下类型支持：仅 `bundler` 和 `gomod`。\n\n告知 Dependabot 维护你供应商化的依赖项以及清单文件定义的依赖项。 当你将代码存储在存储库中时，该依赖项被称为“vendored 依赖项”或“缓存依赖项”，请参阅 [`bundle cache` 文档](https://bundler.io/man/bundle-cache.1.html)和 [`go mod vendor` 文档](https://golang.org/ref/mod#go-mod-vendor)。\n\n有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#updating-vendored-dependencies)”。\n\nDependabot 默认行为：\n\n* 仅维护为 Bundler 标识的清单文件和锁定文件中记录的依赖项。\n* 提出安全更新和版本更新拉取请求，以更新清单文件和锁定文件中记录的版本号。\n* 对于 Go 模块，所有 vendored 依赖项都会被自动识别和维护，如同启用了 `vendor` 一样。\n\n启用 `vendor` 时：\n\n* Dependabot 还维护存储在存储库中的 `_vendor/cache_` 目录内的 Bundler 依赖项。\n* 拉取请求有时会包含对存储在存储库中的依赖项的更新。\n\n支持的值：`true` 或 `false`\n\n## `versioning-strategy`\n\n支持：`bundler`、、、`cargo`、`composer`、`helm``mix``npm`、`pip`、 `pub`和`uv`\n\n请确定如何使用Dependabot编辑manifest文件。 有关示例，请参阅“[控制 Dependabot 更新的依赖项](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-a-versioning-strategy)”。\n\nDependabot 默认行为：\n\n* 尝试区分应用依赖项和库依赖项。\n* 对于应用，始终提高最低版本要求以匹配新版本。 即 `increase` 策略。\n* 对于库，尽可能放宽允许的版本要求，以同时包含新旧版本。 即 `widen` 策略。\n\n定义`versioning-strategy`之后，Dependabot 采用指定的策略。\n\n| 价值 | 行为 |\n| ----------------------- | ----------------------------------------------------- |\n| `auto` | 默认行为。 |\n| `increase` | 始终增加最低版本要求以匹配新版本。 如果范围已存在，通常这只会增加下限。 |\n| `increase-if-necessary` | 如果版本要求已经允许新的发布，则保持不变（Dependabot 仍更新已解析的版本）。 否则，扩大该要求。 |\n| `lockfile-only` | 仅创建用于更新 lockfiles 的拉取请求。 忽略任何需要包清单更改的新版本。 |\n| `widen` | 尽可能放宽允许的版本要求，以包括新旧版本。 通常，这只会增加允许的最大版本要求。 |\n\n例如，如果当前版本为 `1.0.0` 且当前约束为 `^1.0.0`，则不同策略会提出以下更新：\n\n新版本 `1.2.0`\n\n* `increase`：新约束 `^1.2.0`\n* `increase-if-necessary`：新约束 `^1.0.0`\n* `widen`：新约束 `^1.0.0`\n\n新版本 `2.0.0`\n\n* `increase`：新约束 `^2.0.0`\n* `increase-if-necessary`：新约束 `^2.0.0`\n* `widen`：新约束 `>=1.0.0 <3.0.0`\n\n> \\[!NOTE]\n> 如果使用的包管理器尚不支持配置 `versioning-strategy` 参数，或者不支持所需的值，则策略代码开放源代码，因此，如果希望特定生态系统支持新策略，则始终欢迎在 中提交拉取请求。\n\n### 版本控制标签\n\n\n\n* 代表软件发布生命周期的阶段，例如 alpha、beta 和稳定版本。\n* 使发布者能更有效地分发其包。\n* 指示版本的稳定性，并告知用户在功能和稳定性方面可预期的内容。\n\nDependabot 识别各种版本控制标记，用于跨不同生态系统的预发布、稳定版本和自定义标记。\n\n`dependabot.yml` 文件并不决定你可以使用哪些版本标签，但你可以在 [`ignore`](/zh/code-security/reference/supply-chain-security/dependabot-options-reference#ignore--) 等配置选项中定义你想要忽略更新的受支持版本标签。\n\n#### 支持的版本控制标记\n\n\\| **包管理器** |\n**YAML 值** | 支持的标记\\*\\*\\*\\* |\n**示例** |\n\\|---------------------|----------------|--------------------|--------------|\n\\| Maven | `maven` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`spring-security-web@5.6.0-SNAPSHOT`、`spring-core@5.2.0.RELEASE` |\n\\| npm | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@beta`、`react@latest`、`express@next` |\n\\| pnpm | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@1.2.0-alpha`、`react@alpha`、`vue@next` |\n\\| |\n\\| sbt | `sbt` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`akka-actor@2.7.0-RC1`、`play-json@3.0.0-M1` |\n\\| |\n\\| yarn | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@1.2.0-alpha`、`axios@latest`、`moment@nightly` |\n\\| Bundler | `bundler` | 任何预发布标识符（通常为`alpha`、`beta`、`rc`、`pre`） |\n`rails@1.0.0.alpha`、`rack@1.0.0.beta1`、`rspec@1.0.0.rc2` |\n\\| Cargo | `cargo` | 任何 SemVer 预发行版标识符（通常`alpha`，、`beta``rc`、`dev`） |\n`serde@1.0.0-alpha`、`tokio@0.2.0-preview.3`、`clap@4.0.0-rc.1`、`rand@1.0.0-dev` |\n\\| pip | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| pipenv | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| pip-compile | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| poetry | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| Gradle | `gradle` |\n`alpha`、`a`、`beta`、`b`、`milestone`、`m`、`rc`、`cr`、`snapshot`、`ga`、`final`、`release`、`sp`（不区分大小写） |\n`spring-boot-starter@3.0.0-RC1`、`kotlin-stdlib@2.0.0-beta`、`guava@33.0.0-SNAPSHOT`、`junit@5.10.0-M2`、`ktor@2.3.0-rc.1` |\n\\| Elm | `elm` | 无——仅限严格 `MAJOR.MINOR.PATCH`（不含预发布版本） |\n`elm/core@1.0.0`、`elm/html@2.3.1`、`elm/json@10.0.0` |\n\\| Docker | `docker` |\n`alpha`、`beta`、`rc`、`dev`、`preview`、`pre`、`nightly`、`snapshot`、`canary`、`unstable`（启发式检测） |\n`nginx@1.25.0-rc1`、`node@20.0.0-alpha.1`、`redis@7.0.0-nightly`、`alpine@3.18.0-dev`、`ubuntu@22.04-preview` |\n\\| git 子模块 | `gitsubmodule` | 无 - 锁定为提交 SHA 或 Git 标记（不采用版本控制方案） |\n`my-lib@abc1234`、`shared-utils@v1.2.0` |\n\\| Go 模块 | `gomod` |\n`alpha`、`beta`、`rc`（`-` 之后为 SemVer 预发行版） |\n`github.com/go-chi/chi@v5.0.0-rc1`、`google.golang.org/grpc@v1.60.0-beta.1`、`github.com/octo-org/octo-module@v0.17.0-alpha.1` |\n\\| |\n\\| 巴泽尔 | `bazel` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`rules_go@0.46.0-rc1`、`rules_rust@0.40.0-beta`、`bazel_skylib@1.5.0-alpha` |\n\\| |\n\\| Bun | `bun` |\n`alpha`、`beta`, `rc`, `canary`（`-` 之后为 SemVer 预发行版） |\n`bun@1.0.0-beta.1`、`elysia@1.0.0-rc.3`、`hono@4.0.0-canary.1` |\n\\| Composer | `composer` |\n`dev`、、`alpha``a`、`beta`、`b`、 `RC` （不区分大小写） |\n`laravel/framework@11.0.0-alpha1`、`symfony/console@7.0.0-beta2`、`monolog/monolog@3.0.0-RC1` |\n\\| |\n\\| Conda | `conda` |\n`dev`、`alpha`、`a`、`beta`、`b`、`rc`、`c`、`post` |\n`numpy@2.0.0a1`、`pandas@2.1.0b2`、`scipy@1.12.0rc1`、`scikit-learn@1.4.0.dev0` |\n\\| |\n\\| |\n\\| Deno | `deno` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`oak@13.0.0-alpha`、`fresh@2.0.0-rc.1`、`std@0.220.0-beta.2` |\n\\| |\n\\| 开发容器 | `devcontainers` | SemVer 2.0.0 （在实践中未使用的预发行版） |\n`ghcr.io/devcontainers/features/node@1.6.1`、`ghcr.io/devcontainers/features/python@1.6` |\n\\| .NET SDK | `dotnet-sdk` |\n`preview.N`、`rc.N`、`alpha.N` |\n`dotnet-sdk@9.0.100-preview.7.24407.12`、`dotnet-sdk@9.0.100-rc.2.24474.11` |\n\\| GitHub Actions | `github-actions` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`my-org/my-action@v1.0.0-beta.1`、`my-org/deploy@v2.0.0-rc1`、`my-org/lint@v3.0.0-alpha` |\n\\| |\n\\| Helm 图表 | `helm` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`ingress-nginx@4.11.0-beta.0`、`cert-manager@1.15.0-alpha.1`、`prometheus@25.0.0-rc1` |\n\\| |\n\\| Hex | `mix` | 任何 SemVer 预发行版标识符（通常`alpha`，、`beta``rc`、`dev`） |\n`phoenix/phoenix@1.7.0-rc.0`、`elixir-ecto/ecto@3.11.0-beta.1`、`elixir-plug/plug@1.15.0-alpha.1` |\n\\| |\n\\| 朱莉娅 | `julia` | 任何 SemVer 预发行版标识符 （通常 `rc`， `DEV`， `beta`） |\n`HTTP@1.10.0-rc1`、`Plots@2.0.0-DEV`、`DataFrames@1.6.0-beta.1` |\n\\| |\n\\| |\n\\| 尼 克 斯 | `nix` | 无 — 跟踪 flake 输入提交（无版本控制方案） |\n`nixpkgs@a1b2c3d`、`devenv@e4f5a6b`、`flake-utils@c7d8e9f` |\n\\| |\n\\| NuGet | `nuget` | 任何 SemVer 预发行版标识符（通常`alpha`，、`beta``rc`、`preview`） |\n`Newtonsoft.Json@13.0.0-rc1`、`Microsoft.Extensions.Hosting@8.0.0-preview.7`、`Serilog@3.0.0-beta.1` |\n\\| |\n\\| OpenTofu | `opentofu` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`opentofu/aws@5.0.0-alpha`、`opentofu/google@5.0.0-rc1`、`opentofu/azurerm@4.0.0-beta1` |\n\\| |\n\\| |\n\\| pre-commit | `pre-commit` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`pre-commit/mirrors-mypy@1.10.0a1`、`psf/black@24.1.0rc1`、`astral-sh/ruff-pre-commit@0.4.0-beta.1` |\n\\| |\n\\| Pub | `pub` | 任何 SemVer 预发行版标识符 （通常 `dev`， `beta`， `rc`） |\n`flutter/dio@5.0.0-dev.1`、`dart-lang/http@1.2.0-beta.1`、`invertase/melos@4.0.0-rc.1` |\n\\| |\n\\| Rust 工具链 | `rust-toolchain` | 基于频道：`stable`、 `beta`、 `nightly`（而不是 SemVer 预发行版） |\n`rust@1.78.0`、`rust@beta`、`rust@nightly`、`rust@nightly-2024-01-15` |\n\\| |\n\\| Swift | `swift` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`vapor/vapor@5.0.0-beta.1`、`apple/swift-nio@3.0.0-rc1`、`pointfreeco/swift-composable-architecture@2.0.0-alpha.1` |\n\\| Terraform | `terraform` | 任何 SemVer 预发行版标识符 （通常 `alpha`， `beta`， `rc`） |\n`hashicorp/aws@5.0.0-rc1`、`hashicorp/google@4.0.0-alpha`、`hashicorp/azurerm@3.0.0-beta1` |\n\\| uv | `uv` |\n`a`、、`b``rc`、`dev`、 `post` （PEP 440） |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| |\n\\| vcpkg | `vcpkg` | 任何 SemVer 预发行版标识符 （通常 `beta`， `rc`） |\n`zlib@1.3.1-beta1`、`openssl@3.2.0-rc.1`、`fmt@10.2.0-beta` |\n\\| |\n\n#### 特定生态系统的版本编号详细信息\n\n以下详细信息介绍了如何 Dependabot 解释特定生态系统的版本控制。\n\n* **Bundler：** 不使用一组固定的预发布标签。 包含字母的任何版本段都被视为预发行版（例如， `.alpha`， `.beta1`） `.rc2`。 连字符在内部会被规范化为 `.pre.`（例如，`1.0.0-beta` 会变为 `1.0.0.pre.beta`）。\n\n* **货物：** 遵循 SemVer 2.0.0 约定。 之后 `-` 的任何内容都是预发行版标识符（点分隔， `[0-9A-Za-z-]`）。 允许使用构建元数据 (`+...`)，但在确定优先级时会将其忽略。\n\n* **Gradle：** 除了表中列出的限定符外，还识别这些别名：`pr`/`pre`/`preview`→`rc`，`eap`/`ea`→。`alpha` 其他预发行版限定符包括 `dev`， `experimental`和 `unstable`。 限定符按优先级排序：`alpha`/`a` < `beta`/`b` < `milestone`/`m` < `rc`/`cr` < `snapshot`<（空/`ga`/`final`/`release`） <。 `sp` 此列表中没有的自由格式标识符被视为稳定。\n\n* **pip/pipenv/pip-compile/poetry（PEP 440）：** 下表列出了标准预发行版和后发行版后缀。 别名也可识别和规范化（`alpha`→、`a`→`beta``b`、`c`/`pre`/`preview`→`rc`、`rev`/`r`→）。`post` 支持纪元版本 (`N!...`) 和本地版本 (`+local`)；本地段仅在公共版本相同时用于区分。\n\n* **Elm:** 强制遵循严格的 SemVer（`MAJOR.MINOR.PATCH` 仅限整数）。 Elm 包注册表不允许发布预发行版版本。\n Dependabot 以数字方式比较版本。\n\n* **Go 模块：** 遵循带有强制性 `v` 前缀的 SemVer。 伪版本 （`v0.0.0-YYYYMMDDHHMMSS-commithash`） 表示未发布的提交，并且始终被视为预发行版。\n `+incompatible` 后缀用于标记主版本为 2+ 且没有 `go.mod` 文件的模块，并且不会影响版本排序。\n\n* \\*\\*git 子模块：\\*\\*Dependabot 跟踪已配置的分支上的最新提交。 不进行版本比较——更新始终会将固定的 SHA 值向前推进。 如果子模块跟踪某个标签，Dependabot 会跟随该标签对应的提交。\n\n* **巴泽尔：** 遵循 SemVer 预发行版约定。 Bazel Central Registry （BCR） `.bcr.N` 后缀在比较前去除，不会影响预发行版检测。\n\n* **Deno：** 遵循 SemVer 预发行版约定。 支持构建元数据（`+...`），但在版本优先级比较中会忽略它。\n\n* **Bun:** 遵循 npm 风格的 SemVer 预发布约定。 支持构建元数据（`+...`），但在版本优先级比较中会忽略它。\n\n* \\*\\*GitHub Actions：\\*\\*Dependabot 解析 git 标记中的操作版本。 任何具有 SemVer 预发行版标识符的标记（之后 `-`的任何内容）都被视为预发行版。 此外，无论标记格式如何，都会识别通过 GitHub 发布 API 标记为预发行版的版本。\n\n* **朱莉娅：** 遵循 SemVer 预发行版约定。 预发行版标识符区分大小写（例如， `DEV` 且 `dev` 不同）。\n\n* **Hex：** 遵循 SemVer 预发布规范。 之后 `-` 的任何标识符都被视为预发行版。\n\n* \\*\\*尼 克 斯：\\*\\*Dependabot 跟踪 flake 输入提交，类似于 git 子模块。 在内部，版本表示为伪版本（`0.0.0-0.N`）。 没有传统的版本对比 — 更新会直接推进到最新的上游提交。\n\n* **NuGet：** 遵循 SemVer 2.0.0 预发行版约定。 支持构建元数据（`+...`），但在版本优先级比较中会忽略它。\n\n* **OpenTofu：** 遵循 SemVer 预发行版约定（与 Terraform 相同）。 生成元数据（包括 `+backport` 后缀）在比较之前被剥离，不会影响预发行版检测。\n\n* **Rust 工具链：** 使用基于通道的版本控制（`stable`、、 `beta`） `nightly`而不是 SemVer 预发行版标识符。\n Dependabot 将固定频道或带日期戳的每日构建版本（例如 `nightly-2024-01-15`）更新到最新可用版本。\n\n* **Terraform：** 遵循 SemVer 预发行版约定。 比较前会先去除 `v` 前缀。 构建元数据（`+...`）在版本优先级比较中会被忽略。\n\n* **Composer:** 遵循 PHP Composer 的稳定性约定（不区分大小写）。 比较前会去除约束中的稳定性标志 （`@dev`， `@beta`） 。 前缀 `v` 以透明方式处理。\n\n* **Conda：** 遵循 conda 版本规范（类似于 PEP 440）。 支持纪元版本（`N!...`）和本地版本（`+local`）。 可识别发布后 (`post`) 后缀。\n\n* **.NET SDK：** 预发行版标识符遵循模式`preview.N``rc.N``alpha.N`。 预发布更新需要在 `allowPrerelease: true` 中使用 `global.json`。\n\n* **Helm Chart：** 遵循 SemVer 预发布版本规范。 图表版本前缀（例如 `chart-v`）和构建摘要（`+sha256:...`）会在比较前被去除。\n\n* **预提交：** 解析 git 标记中的挂钩版本。 预发布版本检测同时使用 Gem::Version 启发式以及 GitHub Release API 的 `prerelease` 标记。 还支持 SHA 固定挂钩。\n\n* **Pub:** 遵循 SemVer 预发布版本约定。 支持构建元数据（`+...`），但在版本优先级比较中会忽略它。\n\n* **Swift：** 遵循 SemVer 预发布版本规范。 当前未应用预发行版筛选 - 所有版本在比较中均受到同等对待。\n\n* **vcpkg：** 支持多种版本格式：点分隔数字、SemVer（不含生成元数据）和基于日期。 端口版本后缀 （`#N`） 指示打包修订，不会影响预发行版检测。\n\n#### 版本控制标签术语表\n\n* **`alpha`：** 早期版本，可能不稳定且功能不完整。\n* **`beta`：** 比 alpha 更稳定，但可能仍存在 bug。\n* **`canary`：** 定期更新的预发布测试版本。\n* **`dev`：** 代表开发版本。\n* **`experimental`：** 包含实验性功能的版本。\n* **`latest`：** 最新稳定版本。\n* **`legacy`：** 较旧或已弃用的版本。\n* **`next`：** 即将发布的版本。\n* **`nightly`：** 夜间构建版本；通常包含最新更改。\n* **`rc`：** 候选发布版本，接近稳定版本。\n* **`release`：** 正式发布版本。\n* **`stable`：** 最可靠、可用于生产环境的版本。\n\n\n\n## 顶层 `registries` 密钥\n\n指定 Dependabot 可以使用的身份验证详细信息，以访问专用包注册表，包括 GitLab 或 Bitbucket 托管的注册表。\n\n`registries` 项的值是一个关联阵列，其中每个元素由一个标识特定注册表的键和一个为关联阵列的值组成，该值指定访问该注册表所需的设置。 以下 `dependabot.yml` 文件在文件的 `dockerhub` 部分配置一个标识为 `registries` 的注册表，然后在文件的 `updates` 部分中引用该注册表。\n\n```yaml copy\n# Minimal settings to update dependencies stored in one private registry\n\nversion: 2\nregistries:\n dockerhub: # Define access for a private registry\n type: docker-registry\n url: registry.hub.docker.com\n username: octocat\n password: ${{secrets.DOCKERHUB_PASSWORD}}\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/docker-registry/dockerhub\"\n registries:\n - dockerhub # Allow version updates for dependencies in this registry\n schedule:\n interval: \"monthly\"\n```\n\n您使用以下选项来指定访问设置。 注册表设置必须包含 `type` 和 `url`，并且通常包含 `username` 和 `password` 组合或 `token`。\n\n| 参数 | 用途 |\n| :--------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |\n| `REGISTRY_NAME` | |\n| **必需：** 定义注册表的标识符。 | |\n| `type` | |\n| **必需：** 确定注册表的类型。 | |\n| 身份验证详细信息 | |\n| **必需：** 提供身份验证详细信息所支持的参数因不同类型的注册表而异。 | |\n| `url` | |\n| **必需：** 用于访问此注册表中的依赖项的 URL。 协议是可选的。 如果未指定，则假定为 `https://`。 | |\n| Dependabot 会根据需要添加或忽略末尾斜杠。 | |\n| `replaces-base` | 如果布尔值是 `true`， Dependabot 则使用指定的 `url` 而不是该生态系统的基 URL 解析依赖项。 |\n| | |\n| `scope` | 仅适用于 `npm-registry` 类型。 要与此注册表关联的 npm 作用域，例如 `@my-company`。 提供了 `scope` 时，Dependabot 会根据注册表凭据生成 `.npmrc` 配置，并覆盖任何已提交的 `.npmrc` 文件或根据锁文件进行的推断。 |\n| | |\n\n有关可用选项的详细信息，以及配置专用注册表时的建议，请参阅“[针对 Dependabot 的专用注册表配置指南](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries)”。\n\n### `type` 和身份验证详情\n\n用于提供访问专用注册表的身份验证详情的参数因注册表 `type` 而异。\n\n| 注册表 `type` | 必需的身份验证参数 |\n| --------------------------------------------------------------------------- | --------- |\n| `cargo-registry` | `token` |\n| `composer-repository` | |\n| `username` 和 `password`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `docker-registry` | |\n| `username` 和 `password`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `git` | |\n| `username` 和 `password`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `hex-organization` | |\n| `organization` 和 `key` | |\n| `hex-repository` | |\n| `repo` 和 `auth-key` 以及相应的 `public-key-fingerprint`（可选） | |\n| `maven-repository` | |\n| `username` 和 `password`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `npm-registry` | |\n| `username` 和 `password`
或 `token`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `nuget-feed` | |\n| `username` 和 `password`
或 `token`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `pub-registry` | `token` |\n| `python-index` | |\n| `username` 和 `password`
或 `token`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `rubygems-server` | |\n| `username` 和 `password`
或 `token`
或 OIDC 以及 `tenant-id` 和 `client-id` | |\n| `terraform-registry` | `token` |\n\n所有用于身份验证的敏感数据都应安全存储，并从该安全位置引用，请参阅 [为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries)。\n\n> \\[!TIP]\n> 如果帐户是 GitHub 帐户，则可以使用 GitHub personal access token 代替密码。\n\n有关 Dependabot 的 OIDC 支持的详细信息，请参阅 [OpenID Connect](/zh/actions/concepts/security/openid-connect#oidc-support-for-dependabot) 和 [为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#using-oidc-for-authentication)。\n\n### `url` 和 `replaces-base`\n\n`url` 参数定义了访问注册表的位置。 启用 `replaces-base` 参数（可选）时，`true` 使用 Dependabot 的值来解析依赖项，而不是使用该特定生态系统的基 URL。\n\n### `scope`\n\n该 `scope` 参数可用于 `npm-registry` 类型注册表。 它指定应与注册表关联的 npm 范围。 该值必须以 `@` 开头，例如 `@my-company`。 若要将多个范围与同一注册表 URL 相关联，请为每个范围创建单独的注册表项。\n\n当提供 `scope` 时，Dependabot 会从你的注册表凭据生成 `.npmrc` 配置。 此生成的配置优先于任何已提交的 `.npmrc` 文件或基于锁定文件的推断。\n\n#### npm 注册表解析的优先级顺序\n\n确定要用于 npm 依赖项的注册表时， Dependabot 请遵循以下优先级顺序：\n\n1. **基于凭据的生成（`scope` 或 `replaces-base`）：** 如果在 `scope` 中的任何 `replaces-base` 凭据上配置了 `npm-registry` 或 `dependabot.yml`，则 Dependabot 会根据这些凭据生成 `.npmrc`。 这始终优先，覆盖任何提交的 `.npmrc` 文件。\n2. **存储库中已提交的 `.npmrc`：** 如果未设置 `scope`，Dependabot 将使用已提交到存储库中的任意 `.npmrc` 文件。\n3. **锁定文件推断（过渡阶段）：** 如果没有 `scope`，且未提交 `.npmrc`，Dependabot 会尝试从锁定文件中推断注册表配置。\n4. **报错：** 如果上述方法都未成功，Dependabot 会报告错误，并提示添加显式配置。"}