Как настроить Dependabot: группировка обновлений, ежемесячный график и безопасность

Если вы поддерживаете активный репозиторий, то знакомы с ситуацией: утром в понедельник вы открываете уведомления и видите пять, десять, а то и дюжину pull request от Dependabot, каждый из которых обновляет одну зависимость на одну патч-версию. По отдельности они полезны, но вместе создают шум, из-за которого важные обновления могут быть проигнорированы. В блоге GitHub инженеры Microsoft показали, как этого избежать на примере проекта GCToolkit.

Проблема: хорошие настройки по умолчанию, но неправильная частота

Исходная конфигурация GCToolkit выглядела так:

version: 2
updates:
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 10

Две особенности делали эту конфигурацию шумной:

• Ежедневная проверка — Dependabot проверял обновления каждый будний день, что приводило к новым PR в любой день недели.
• Отсутствие группировки — каждая зависимость получала собственный PR. Десять обновлений — десять PR, десять CI-запусков и десять уведомлений. Параметр open-pull-requests-limit: 10 лишь ограничивал количество открытых PR, но не уменьшал поток.

Решение: три изменения, которые работают вместе

После изменений конфигурация стала такой:

version: 2
updates:
- package-ecosystem: "github-actions"
  directory: "/"
  schedule:
    interval: "monthly"
  groups:
    monthly-batch:
      patterns:
      - "*"
- package-ecosystem: "maven"
  directory: "/"
  schedule:
    interval: "monthly"
  groups:
    monthly-batch:
      patterns:
      - "*"

1. Группировка всех обновлений в один pull request

Блок groups — ключевое изменение:

groups:
  monthly-batch:
    patterns:
    - "*"

Группа Dependabot объединяет несколько обновлений зависимостей в один PR. Имя группы (monthly-batch) выбирается разработчиком и отображается в заголовке PR и имени ветки. Шаблон "*" — это wildcard, который включает все зависимости. Вместо десяти PR вы получаете один с заголовком вроде «Bump the monthly-batch group with 10 updates». Одна ветка, один CI-запуск, одна проверка. Если всё зелёное — один merge.

Для крупных проектов можно определить несколько групп с более точными шаблонами, например, отдельно для тестовых и production-зависимостей.

В феврале 2026 года Dependabot получил возможность группировать обновления одной и той же зависимости из нескольких директорий в один PR. Это особенно полезно для монорепозиториев: если одна библиотека используется в десятке сервисов, раньше каждое обновление создавало десяток почти одинаковых PR. Теперь можно указать список директорий (ключ directories во множественном числе) или glob-шаблон, например /apps/*, и группа объединит все обновления в один PR.

2. Замедление с ежедневного до ежемесячного графика

schedule.interval: "monthly" меняет ритм с «когда угодно» на «один раз в месяц по расписанию». В сочетании с группировкой это даёт реальное снижение шума: Dependabot открывает один сгруппированный PR на экосистему в месяц вместо постоянного потока.

Для зрелых библиотек со стабильными зависимостями ежемесячный интервал — правильный выбор. Если нужно что-то среднее, доступен еженедельный интервал с возможностью указать точный день и время.

3. Охват всех используемых экосистем

Исходная конфигурация GCToolkit проверяла обновления только для github-actions. Но проект написан на Java с Maven, поэтому его основные зависимости не получали обновлений Dependabot. Обновлённая конфигурация добавляет вторую запись для Maven. Каждая экосистема получает собственный график и собственную группу, так что обновления Actions и Maven приходят двумя чистыми отдельными батчами.

Что насчёт обновлений безопасности?

По умолчанию группы и график, заданные в конфигурации, влияют только на обновления версий, а не на исправления безопасности. Dependabot security updates создаются сразу после раскрытия уязвимости, независимо от вашего расписания и отдельно от групп обновления версий. Таким образом, ежемесячный батч для рутинных обновлений не задерживает критические патчи. (Можно намеренно группировать исправления безопасности с помощью applies-to: security-updates, но даже в этом случае они инициируются раскрытием уязвимости, а не вашим расписанием.)

Однако эта защита работает только если Dependabot security updates включены для репозитория, что также требует включения dependency graph и Dependabot alerts. Убедитесь, что они включены, прежде чем полагаться на медленный график обновления версий.

Новая защита: трёхдневная задержка по умолчанию

Недавно Dependabot получил ещё одну функцию снижения шума, которая работает автоматически. Теперь Dependabot ждёт не менее трёх дней после публикации нового релиза в реестре, прежде чем открыть PR на обновление версии. Эта задержка включена по умолчанию и не требует настройки.

Почему ждать? Новый релиз — один из самых распространённых векторов атак на цепочку поставок. Скомпрометированная или просто сломанная версия может попасть в ваши обновления до того, как сообщество и мейнтейнеры успеют отреагировать. Короткая задержка даёт время, чтобы сигнал о проблеме проявился.

Два важных момента:

• Задержка применяется только к обновлениям версий. Исправления безопасности открываются немедленно.
• Вы можете настроить задержку с помощью опции cooldown в .github/dependabot.yml, например увеличить до 7 дней или отключить полностью.

Как применить этот паттерн к своим репозиториям

1. Откройте (или создайте) файл .github/dependabot.yml в ветке по умолчанию вашего репозитория.
2. Для каждой экосистемы, от которой вы зависите, установите schedule.interval в weekly или monthly.
3. Добавьте блок groups с одним wildcard-шаблоном (patterns: ["*"]), чтобы объединить обновления в один PR на экосистему.
4. Убедитесь, что перечислены все экосистемы, которые вы используете: не только github-actions, но и maven, npm, pip, gomod, docker и т.д.
5. Закоммитьте изменения — следующий запланированный запуск создаст один сгруппированный PR.

Что это значит

Обновление зависимостей — рутина, которую легко автоматизировать и затем начать игнорировать, что сводит на нет всю пользу. Решение не в том, чтобы отключить Dependabot или сливать PR не глядя, а в том, чтобы настроить его вывод: рутинная работа должна быть тихой и пакетной, а срочная — пробиваться сквозь шум. GCToolkit сделал это примерно дюжиной строк YAML: сгруппировал всё, замедлил до месяца и охватил все экосистемы. Добавьте новую задержку по умолчанию — и даже ежемесячный батч успеет «отстояться» несколько дней. Результат: меньше PR, меньше CI-запусков и, главное, очередь на ревью, где важные обновления не теряются среди неважных.

Информация опубликована в блоге GitHub.