Я завершил автоматизацию процесса обновления зависимостей для моего pet-проекта. Теперь Dependabot проверяет наличие обновлений и создаёт pull-реквесты. После успешного прохождения всех проверок изменения автоматически вливаются в основную ветку.

Зачем все это

Воспроизводимость сборки и пакетов — это фундамент разработки проектов любого масштаба. В ее отсутствии кратно возрастают затраты на построение проекта и пакетов, так как приходиться подбирать рабочие конфигурации и окружение. А также часто возникают ситуации «а у меня все работает».

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

Однако воспроизводимость не даётся бесплатно. Зависимости нужно периодически обновлять — ради безопасности, новых возможностей или совместимости. И именно эти усилия по обновлению и тестированию становятся платой за стабильность и предсказуемость сборки.

Существующие подходы

В целом, подходы к обновлению зависимостей варьируются от полного контроля вручную до полной автоматизации. Рассмотрим кратко два крайних случая: полностью ручной и полностью автоматический.

Ручной подход позволяет проводить более осознанное обновление зависимостей: разработчики изучают изменения, принимают взвешенные решения об интеграции новых версий и заранее минимизируют возможные проблемы. Такой подход особенно ценен в критичных или сложных проектах. Однако осознанность требует времени и усилий, которые растут пропорционально количеству зависимостей. В больших проектах ручное обновление может стать серьёзной нагрузкой.

Автоматический подход, напротив, обеспечивает высокую степень автономности. Обновления происходят регулярно и без участия разработчиков, что экономит их время. Но при этом возрастает нагрузка на CI-инфраструктуру: требуется дополнительное машинное время для проверки интеграции каждой новой версии, а также надёжное тестовое покрытие для выявления регрессий. Кроме того, автоматическое обновление может создавать «шум» в истории коммитов — большое количество мелких изменений, не всегда значимых с точки зрения логики проекта.

Выбор подхода

То, где именно окажется подход к обновлению зависимостей в проекте между двумя крайностями — зависит от специфики проекта, предъявляемых к нему требований и доступных ресурсов.

В моем случае — это open source pet-проект, размещённый на GitHub и развиваемый исключительно в свободное время. Поэтому мне важно минимизировать ручной труд, связанный с поддержкой зависимостей, даже если это приведёт к некоторому «шуму» в истории коммитов. К тому же GitHub предоставляет бесплатные ресурсы для GitHub Actions (GA) для open source проектов, что делает привлекательной автоматизацию для проекта с использованием GA. В результате я решил максимально автоматизировать процесс обновления зависимостей, используя предоставляемые GitHub инструменты: Dependabot и GA.

Настройка Dependabot

Настройка Dependabot для маленького проекта ничем особо не отличается от примеров из документации: Configuring Dependabot version updates. И в моем конкретном случае выглядит как:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directories: [".github/workflows", ".github/actions/**"]
    schedule:
      interval: "daily"
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"

Здесь обязательное поле version, которое может принимать только значение 2. И секция updates, в ней описываются настройки для каждого отдельного пакетного менеджера:

• package-ecosystem – определяет какая экосистема зависимостей отслеживается;

• directories – список каталогов, в которых будут искаться файлы определяющие зависимости;

• schedule – расписание проверок новых версий

После того как файл конфигурации (.github/dependabot.yml) будет добавлен в основную ветку, Dependabot начнет проверку зависимостей согласно заданному расписанию. И как только появится новая версия для зависимости, он создаст pull-реквест на ее обновление.

Настройка GitHub Actions

В целом, реализация CI-пайплайна ограничена лишь фантазией и доступными ресурсами. Главное, чтобы он запускался при создании pull-реквестов. А тестовое покрытие позволяло выявлять регрессии при обновлении зависимостей.

Для автоматического аппрува и мерджа можно использовать пример из официальной документации: Automating Dependabot with GitHub Actions.

Единственный нюанс, который здесь стоит отметить, что если есть workflow настроенный на push в основную ветку, то автоматический мердж изменений, сделанный с использованием GITHUB_TOKEN согласно примеру из документации выше, не запустит такой workflow. Это ограничение описано в разделе Triggering a workflow и введено для предотвращения рекурсивных вызовов. Чтобы обойти это ограничение, можно вручную запустить нужный workflow сразу после мерджа изменений. Например, код ниже производит слияние изменений с основной веткой, а после запускает workflow на push в основную ветку:

- name: Merge a PR
  run: |
    gh pr merge "${{github.event.pull_request.html_url}}" \
                --delete-branch --squash
    gh workflow run ci-main-push.yml \
                --ref "${{github.event.pull_request.base.ref}}" \
                --repo "${{github.event.pull_request.base.repo.html_url}}"
  env:
    GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

Итог

С помощью связки Dependabot + GitHub Actions удалось полностью автоматизировать процесс обновления зависимостей в проекте, практически исключив ручной труд. При этом сохранив контроль над качеством благодаря CI-пайплайну и тестовому покрытию.

Полные конфигурации Dependabot и GitHub Actions доступны в репозитории проекта на GitHub.

Альтернативы

Хотя Dependabot поддерживает множество экосистем, хорошо интегрирован с GitHub и с ним возможна полная автоматизация обновления зависимостей для небольших проектов. Его возможности настройки остаются довольно ограниченными и их может не хватить для реализации сложных сценариев.

В таких случаях стоит рассмотреть Renovate как более гибкую альтернативу. Этот инструмент предлагает расширенные возможности кастомизации, позволяя адаптировать процесс обновления зависимостей под специфические требования проекта. И он получил статус Adopt в Technology Radar Vol. 32 (April 2025), что означает рекомендацию к активному использованию.