Renovate, альтернатива Dependabot

Я не буду представлять Dependabot. Многие и многие разработчики используют его ежедневно на GitHub. Я тоже им пользуюсь. Однако он страдает от двух недостатков:

  • Хотя он отлично интегрирован с GitHub, интеграция с другими платформами проходит менее гладко.
  • Например, я обычно использую файлы Docker Compose для своих демо-версий. При необходимости я использую Kubernetes. Dependabot не поддерживает ни одну из них.

    Хуже того, Dependabot не принимает взносы для добавления новых экосистем.

Недавно я посмотрел доклад Виктора Фарсика Automate Dependency Management With Renovate. Renovate показался мне очень интересным, я подумал о его использовании и… забыл. Затем я наткнулся на еще одно упоминание о нем. Это подтолкнуло меня к его внедрению в двух местах:

  • В моем блоге
  • Для демонстрации с использованием Docker Compose

Поддерживать мой блог в актуальном состоянии

Я уже неоднократно писал об инфраструктуре моего блога. В контексте этой заметки важны следующие моменты:

  • Он основан на Jekyll. Jekyll — это генератор статических сайтов на основе Ruby. Для управления зависимостями Ruby gems я использую bundler.
  • Я генерирую сайт при каждом запуске на GitLab. Я настроил сборку через стандартный файл .gitlab-ci.yml.
  • Наконец, чтобы не собирать всю инфраструктуру при каждой сборке, я полагаюсь на Dockerfile. Он предоставляет базовый образ JRuby и несколько необходимых двоичных файлов, например, graphviz. Сборка на GitLab начинается с этого образа.

Renovate предлагает инструкции по установке продукта для GitLab. Поскольку мне нужно было понять, как работает Renovate и как его установить, мне пришлось обратиться к довольно большому количеству сайтов.

Вот краткое изложение моего понимания:

  • Для запуска Renovate необходимо создать специальный проект на GitLab.
  • Планировщик GitLab должен запускать его, например, еженедельно или ежедневно
  • Renovate имеет два типа конфигурации: одна относится к самому исполнителю, а другая — к проекту. Если вы задаете параметры для бегуна, они будут применяться к каждому проекту, в котором работает Renovate. В документации рекомендуется, чтобы каждый проект получал свою особую конфигурацию. Обратите внимание, что Renovate предлагает механизм для факторизации конфигурации в разных проектах.

В итоге я получил следующую конфигурацию бегуна Renovate:

variables:
  RENOVATE_GIT_AUTHOR: Renovate Bot <bot@renovate.com>
  RENOVATE_REQUIRE_CONFIG: optional

include:
    - project: 'renovate-bot/renovate-runner'
      file: '/templates/renovate-dind.gitlab-ci.yml'                    #1
Вход в полноэкранный режим Выход из полноэкранного режима
  1. Шаблон предоставляет солидный набор значений по умолчанию, например, переменные окружения: платформа — GitLab, уровень журнала — info и т.д.

По умолчанию Renovate «вынюхивает», какие менеджеры пакетов использует проект. В моем блоге он также проверял HTML-файлы. Чтобы уменьшить объем, я настроил только необходимые менеджеры пакетов:

{
  "enabledManagers": ["gitlabci", "dockerfile", "bundler"]
}
Войти в полноэкранный режим Выйти из полноэкранного режима

Это позволяет управлять зависимостями только GitLab CI, Docker и Bundler.

Вы можете установить переменную окружения LOG_LEVEL в значение debug, особенно в начале; это очень помогает. Например, мои первые несколько запусков останавливались с загадочным сообщением Repository is disabled - skipping. С помощью протоколирования на уровне отладки я смог понять, почему: DEBUG: MRs отключены для проекта - выкидывает ошибку, чтобы прервать обновление.

Следующий шаг — достижение желаемых результатов. В моем случае Renovator не открыл ни одного запроса на слияние.

  • GitLab CI:

    В файле сборки мой образ упоминается с latest, а образ Kaniko — с debug. Ни одно из них не является смысловым, и Renovate не может дать никакого совета. Хотя меня не волнует первое, меня волнует второе. Примечание для моего будущего «я»: Я должен это исправить.

  • Docker:

    Dockerfile использует jruby:9.3-jre11 в качестве родительского образа. Хотя это не семантическая версия, Renovate может извлечь правильную семантическую версию (как видно из журнала: "currentVersion": "9.3",). Однако более новой версии не существует, и Renovate корректно ничего не делает.

  • Драгоценные камни:

    Я использую Bundler, и зависимости прикреплены в файле Gemfile.lock. По умолчанию Renovate не предлагает никакого обновления.

Для GitLab и Docker можно ожидать результатов: никакого семантического версионирования и никакой более поздней версии. В случае с Gems я был несколько озадачен. Причина кроется в том, как Renovate обрабатывает обновления.

По умолчанию используется стратегия replace:

Заменить диапазон на более новый, если новая версия попадает за его пределы, и ничего не обновлять в противном случае.

Другая стратегия — update-lockfile:

Обновлять файл блокировки, когда доступны обновления в диапазоне, иначе заменять для обновлений вне диапазона. Пока работает для bundler, composer, npm, yarn, terraform и poetry.

Это кажется гораздо более разумным. Я обновил конфигурационный файл Jekyll:

{
  "enabledManagers": ["gitlabci", "dockerfile", "bundler"],
  "packageRules": [
    {
      "matchManagers": ["bundler"],                           #2
      "rangeStrategy": "update-lockfile"                      #1
    }
  ]
}
Войти в полноэкранный режим Выход из полноэкранного режима
  1. Обновить стратегию диапазона для применения
  2. Только для Bundler — это не имеет смысла для GitLab или Docker.

Я повторно выполнил задание Renovate, и на этот раз у меня был готов запрос на слияние! Renovate правильно определил обновляемые зависимости, обновил их и создал MR.

 4 |  4 |   | addressable (2.8.0)
 5 |  5 |   |   public_suffix (>= 2.0.2, < 5.0)
 6 |  6 |   | asciidoctor (2.0.17)
 7 |  7 | - | asciidoctor-diagram (2.2.1)
   |  8 | + | asciidoctor-diagram (2.2.3)
 8 |  9 |   |   asciidoctor (>= 1.5.7, < 3.x)
 9 | 10 |   |   asciidoctor-diagram-ditaamini (~> 1.0)
10 | 11 |   |   asciidoctor-diagram-plantuml (~> 1.2021)
11 |    |   |   rexml
12 |    | - | asciidoctor-diagram-ditaamini (1.0.1)
13 |    | - | asciidoctor-diagram-plantuml (1.2022.1)
   | 12 | + | asciidoctor-diagram-ditaamini (1.0.3)
   | 13 | + | asciidoctor-diagram-plantuml (1.2022.5)
14 | 14 |   |   colorator (1.1.0)
15 | 15 |   |   concurrent-ruby (1.1.10)
16 | 16 |   |   cssminify2 (2.0.1)
Вход в полноэкранный режим Выход из полноэкранного режима

Вот фрагмент журнала, показывающий волшебство:

{
  "depName": "asciidoctor-diagram",
  "managerData": {"lineNumber": 10},
  "datasource": "rubygems",
  "depTypes": ["jekyll_plugins"],
  "lockedVersion": "2.2.1",
  "depIndex": 7,
  "updates": [
    {
      "bucket": "non-major",
      "newVersion": "2.2.3",
      "newMajor": 2,
      "newMinor": 2,
      "updateType": "patch",
      "isRange": true,
      "isLockfileUpdate": true,
      "branchName": "renovate/asciidoctor-diagram-2.x-lockfile"
    }
  ],
  "warnings": [],
  "versioning": "ruby",
  "currentVersion": "2.2.1",
  "isSingleVersion": true,
  "fixedVersion": "2.2.1"
}
Вход в полноэкранный режим Выход из полноэкранного режима

Поддержание демо-версии в актуальном состоянии

Хотя я размещаю свой блог в частном репозитории на GitLab, все мои демо-версии являются публичными репозиториями на GitHub. Как я уже говорил, интеграция Dependabot на GitHub превосходна. Однако она оставляет без внимания несколько менеджеров пакетов, которые я регулярно использую, файлы Docker Compose и манифесты Kubernetes. Renovate приходит на помощь!

Настроить Renovate на ваши репозитории проще простого. Просто откройте приложение GitHub Renovate и нажмите на большую кнопку Install в правом верхнем углу. Выберите, в какой организации и в каких репозиториях вы будете устанавливать Renovate.

Renovate откроет Pull Request в каждом соответствующем репозитории. Сайт PR содержит единственный файл, файл конфигурации renovate.json. Вы можете обновить его в соответствии со своими потребностями: вариантов конфигурации множество!

С этого момента Renovate будет следить за настроенными репозиториями и отправлять PR, например, в них:

  • Dockerfile
  • docker-compose.yml

Более того, Renovate Bot ограничивает количество PR, чтобы соблюсти ограничение скорости GitHub. Для удобства он отправляет специальный выпуск под названием «Dependency Dashboard», где можно увидеть все доступные обновления зависимостей.

Как взаимодействовать с приборной панелью, довольно просто. Просто отметьте соответствующий флажок, и откроется PR относительно зависимости. Renovate также будет открывать PR, если их количество ниже установленного лимита.

Заключение

Renovate — отличный инструмент. Он легко работает на GitHub; на GitLab вам понадобится специальный бегун.

По сравнению с Dependabot, мне нравится возможность Renovate обновлять файлы Docker, Docker Compose и Kubernetes. Я буду использовать его и впредь.

Идем дальше:

  • Документация по Renovate
  • Менеджеры Renovate
  • GitLab Renovate runner

Первоначально опубликовано на A Java Geek 21 августаst, 2022

Оцените статью
devanswers.ru
Добавить комментарий