Dependabot 支持仓库级运行器设置：私有依赖更新可按项目选择环境
GitHub在2026年9月29日新增Dependabot仓库级运行器设置。仓库管理员可为版本更新与安全更新选择运行器类型，并按需配置标签和运行器组；带标签的运行器可指向自托管或较大型GitHub托管环境。此次设置面向github.com的私有和内部仓库，公开仓库与GitHub Enterprise Server不显示这些控件。官方更新。
图：AI生成依赖更新运行环境概念配图，非产品界面或性能实测图。
先核对默认值与管理范围
官方说明，选择Labeled runner而未指定标签时使用dependabot标签；也可选标准GitHub运行器。当前安全配置不会强制执行Dependabot运行器设置。团队因此需要明确仓库级选择如何记录与检查，不能以为组织层面已有安全配置，就自然覆盖了这项新设置。
独立分析：给私有依赖做一次最小链路验证
一个常见场景是应用依赖公司内部包源。配置运行器后，应先选一个允许测试的依赖更新，检查任务是否被分派到预期环境、能否读取必需的包元数据，以及最终是否产生可审核的更新结果。排查时把调度、网络连通和包源认证分别记录，否则很容易把任何失败都归因于标签写错。
还应测试环境暂时不可用时会发生什么：任务是否排队、提示是否清楚、谁能看到失败、谁负责恢复。不要只在运行器空闲的理想时段测试；如果依赖更新总是与繁重构建争抢同一资源，排队时间可能比运行时间更影响及时性。
标签要便于识别，隔离要单独验证
标签的作用是让工作找到匹配环境。建议采用表达用途的命名，并维护对应的所有者、可访问包源和使用范围清单。即使某个标签看起来像“专用安全区”，也仍需检查实际运行器组授权和网络权限，不能用名字代替边界验证。相关标签行为可参阅官方文档。
最后为每次调整保留原设置、调整原因和验证结果。先在少量仓库试用，观察更新成功率、等待时长和失败类型，再推广到相似项目。项目级环境选择带来更细的控制，也增加了配置分散的可能；一份清晰的责任清单，往往比多加几个标签更能保证依赖更新长期稳定。
核对时间：2026年10月1日（北京时间）。发布事实依据所链接的一手资料，实践建议为本站独立分析；测试状态、可用范围与文档可能继续更新。
