Я завершил автоматизацию процесса обновления зависимостей для моего 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), что означает рекомендацию к активному использованию.