ROSA Updates Builder — автоматическое обновление пакетов из апстрима (Денис Силаков, OSSDEVCONF-2013) — различия между версиями

== Видео ==

{{vimeoembed|75378859|800|500}}
{{youtubelink|kX_W6Wq7vJ4}}{{letscomment}}


<!-- pollholder --> 










== Слайды ==

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

<references/>






<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-25T01:53:5031T16:34:18.934603023685|vimeo_comments=0|vimeo_plays=160|youtube_comments=0|youtube_plays=44}}

[[Категория:OSSDEVCONF-2013]]
[[Категория:Инструменты майнтейнеров]]
[[Категория:ROSALab]]
[[Category:ROSA Linux]]
[[Category:Инструменты майнтейнеров]]

Текущая версия на 12:19, 4 сентября 2021

Аннотация

Докладчик

Денис Силаков

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

Помноженное на частые релизы в апстриме, большое количество пакетов в дистрибутиве делает эту задачу достаточно ресурсоемкой. Однако процесс обновления пакета во многих случаях тривиален и сводится к замене архива с исходным кодом. Поэтому представляется разумным автоматизиро- вать задачу мониторинга выхода новых версий в апстриме и их сборки в дистрибутив. Данный доклад посвящен инструменту Updates Builder, используемому для этих целей в РОСЕ.

Видео

Слайды

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

Например, ROSA Desktop Fresh R1 содержит около 1,500 пакетов с модулями texlive, более 2,000 модулей Perl, сотни дополнительных пакетов для R и так далее.

Минорные обновления многих подобных компонентов выходят достаточно часто. Как правило, обновление пакета при этом сводится к упаковке новой версии и базовой проверке того, что обновленный пакет устанавливается и им можно пользоваться. В случае одного пакета это недолго — скачать и запаковать новую версию можно за пять минут.

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

К тому же появление новых версий в апстриме надо своевременно отслеживать, и делать это вручную — тоже не очень разумно.

Для облегчения жизни мэйнтейнеров, использующих среду сборки ABF (в настоящее время — прежде всего разработчиков ROSA и OpenMandriva), мы разработали автоматический cервис отслеживания и сборки новых версий ПО. Сервис состоит из двух компонентов — инструмента мониторинга апстрим-версий и инструмента автоматической сборки этих версий на ABF.

В роли первого инструмента выступает Upstream Tracker, который в настоящее время также развивается РОСОЙ. Для целей сервиса используется его часть, отслеживающая актуальность версий пакетов в РОСЕ и OpenMandriva — Updates Tracker, который осуществляет мониторинг апстрима и всегда располагает сведениями о свежих версиях ПО.

Второй инструмент — это утилита Updates Builder, берущая на вход имя пакета, запрашивающая Upstream Tracker на предмет наличия новой версии в апстриме и в случае наличия таковой, пытающаяся ее собрать на ABF. Перед сборкой в Git-репозитории соответствующего проекта на ABF создается отдельная ветка, с которой и работает Updates Builder.

В spec-файле в этой ветке обновляются версия пакета и версия архива с исходным кодом и сбрасывается релиз. Новый архив с исходным кодом помещается в файловое хранилище ABF (в отличие от многих систем сборки, ABF хранит бинарные файлы на отдельном файловом сервере, а в Git помещается только ссылка на нужный файл).

На основе данных из созданной ветки Git осуществляется попытка собрать обновленный пакет. Сборка производится в отдельный контейнер, без публикации пакета в какой-либо репозиторий. Мэйнтейнеру пакета отсылается уже письмо о результатах сборки. В случае успеха он может сразу переходить к проверке функциональности обновленной программы, и если его все устраивает, то перенести новую версию из вспомогательной ветки Git в ветку, соответствующую целевому репозиторию. В дополнение к этому, в случае успешной сборки Updates Builder автоматически формирует Pull Request на перенос обновлений в основную ветку Git — так что мэйнтейнеры могут быстро просмотреть предлагаемые изменения и согласиться с ними нажатием одной кнопки.

Updates Builder уже более полугода успешно используется в РОСЕ и OpenMandriva для отслеживания обновлений нескольких тысяч пакетов. Практика его использования показывает, что один человек вполне в состоянии обрабатывать до нескольких десятков пакетов за неделю, не сильно отвлекаясь от других занятий. Это позволяет повысить эффективность участия в поддержке дистрибутива людей, которые могут выделить на такое участие достаточно ограниченное количество времени.

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

В РОСЕ с такой проблемой борются регламентными мерами — обновления пакетов в main-репозиторий уже выпущенных релизов, а также разрабатываемых релизов на стадии бета-тестирования, обя- заны проходить через команду QA. И в интересах мэйнтейнера перед отправкой обновления на проверку удостовериться в его корректности.

Кроме того, полностью автоматическое обновление с использованием Updates Builder возможно только в случае относительно небольших изменений, которые вряд ли нарушат совместимость с предыдущей версией. В случае серьезных изменений (например, нового soname у библиотеки), мэйнтейнерам все равно придется вмешаться. И в таких случаях все зависит от их добросовестности — ограничатся ли они простым изменением soname в spec-файле или честно изучат проблемы, которые может такое изменение привнести. В конце концов, сервис избавляет их от изрядной доли рутинной работы — так почему бы не потратить освободившееся время на более тщательную проверку новых версий?

Примечания и отзывы

Plays:204   Comments:0