29 сентября GitHub добавил возможность конфигурации раннеров для Dependabot на уровне отдельного репозитория. Ранее настройки были доступны только на уровне организации. Обновление касается приватных и внутренних репозиториев на github.com — для публичных репозиториев и GitHub Enterprise Server управление скрыто.
Что изменилось
Администратор репозитория теперь может указать тип раннера, опциональную кастомную метку и группу раннеров для двух типов задач Dependabot: обновления версий зависимостей (version updates) и обновления безопасности (security updates). Настройка находится в разделе Settings → Advanced Security → Dependency scanning → Dependabot version updates.
Доступны два варианта:
- Standard GitHub runner — стандартный хостед-раннер GitHub, используется по умолчанию. Если выбран этот тип, Dependabot запускается на ubuntu-latest под управлением GitHub Actions.
- Labeled runner — администратор может указать кастомную метку (если не указана, используется метка dependabot) и опционально группу раннеров. Это позволяет направить выполнение на self-hosted раннеры или более крупные хостед-раннеры GitHub.
Новая настройка не запускает Dependabot повторно — изменения вступают в силу при следующем плановом или ручном запуске.
Кому это нужно
Основной сценарий — проекты, использующие приватные реестры пакетов, внутренние библиотеки или специализированные окружения, к которым у стандартных раннеров GitHub нет доступа. Например, если репозиторий зависит от пакетов из приватного PyPI, npm или Maven, self-hosted раннер с настроенной аутентификацией может выполнять обновления Dependabot, не раскрывая учетные данные через IP-адреса GitHub Actions.
Второй сценарий — разделение ресурсов: для одного репозитория можно выделить более мощный раннер, для другого — стандартный, без необходимости настраивать это централизованно для всей организации.
Ограничения, которые стоит учитывать
GitHub прямо указывает, что конфигурации безопасности (security configurations) на данный момент не принуждают использовать настройки раннеров Dependabot. То есть если в организации настроена политика безопасности, которая переопределяет параметры репозитория, настройка раннера может быть проигнорирована.
Также важно: если в организации отключены GitHub Actions или self-hosted раннеры, настройка Labeled runner не сработает — нужно обратиться к администратору организации.
Еще один нюанс: Dependabot на GitHub Actions использует метку ubuntu-latest для выбора раннера. Если в организации есть self-hosted раннеры с такой же меткой, они могут перехватывать задачи Dependabot. GitHub рекомендует не назначать метку ubuntu-latest self-hosted раннерам, если это не предполагается намеренно.
Как проверить настройку
Чтобы убедиться, что изменения работают корректно, администратору репозитория нужно:
Перейти в Settings → Advanced Security → Dependabot version updates.
Выбрать Labeled runner.
3. Указать метку (например, private-registry-runner) и, если нужно, группу.
4. Сохранить.
После этого при следующем запуске Dependabot он должен появиться в логах GitHub Actions под указанным раннером. Если раннер с такой меткой не найден, задача не выполнится — необходимо заранее убедиться, что раннер зарегистрирован и доступен репозиторию.
Практический вывод
Для команд, которые уже используют self-hosted раннеры для доступа к приватным реестрам, это упрощение: не нужно настраивать организационные политики для каждого репозитория по отдельности. Для тех, кто только планирует миграцию, документация GitHub рекомендует сначала убедиться, что Dependabot работает на GitHub Actions, а затем переключать на self-hosted.
Функция доступна сейчас. Подробнее — в документации GitHub по настройке Dependabot на self-hosted раннерах.
