LINUX.ORG.RU

Помогите найти кошерный workflow разработки и сборки RPM пакетов из git

 , , , ,


2

4

Как-то в упор мне не верится то, что все люди обходятся какими-то собственными костылями (как я), а особенно такие монстры как redhat. Есть же наверное какая-то хорошая система, в свободном доступе итд, которая поможет в следующей ситуации:

Есть проект, состоящий из нескольких GIT репозиториев:

  • модуль для iptables
  • ядерный модуль для netfilter
  • набор userspace утилит для работы с этим самым модулем и не только
  • набор автотестов, которые имеет смысл запускать только на настроенном стенде
  • сам spec-файл (вернее его шаблон).

Иными словами мы получаем от каждого репозитория набор исходников, часть из которых нужно сперва собрать (некоторым нужно особое окружение, в данном случае развёрнутые исходники ядра Linux нужной версии), часть просто скопировать и в итоге получить содержимое RPM'ки.

Плюс хочется чтобы поддерживались:

  • сборки пакета из различных веток, скажем, master, devel, experimental, автоматическое подтягивание изменений из master в devel, из devel во все остальные, при сборке.
  • автоинкремент билда.
  • автоматическая генерация ChangeLog из коммитов в git
  • выкладывание собранных RPM на удалённый сервер (складывание в публичный репозиторий).
  • ругань на незакоммиченные изменения и неразрешённые конфликты в репозиториях
  • поддержка CI, хотя бы на уровне «закинуть на стенд, попробовать установить».

В общем хочется чего-то в следующем духе: установил centos, настроил сеть, поставил yum'ом систему сборки, подложил конфиг с другой системы или из бэкапа (мало ли, всё сгорит), запустить эдакий bootstrap и на выходе получить рабочую систему сборки, ничем не отличающуюся от других.

Пока копал в сторону Mock, но судя по описаниям он годится только на то, чтобы пересобирать уже имеющиеся src.rpm под разные архитектуры.

Просто, если такой системы не существует, то, наверное мне стоило бы выложить свой набор костылей в opensource, но чтобы это сделать, мне нужно побороть свой стыд и подчистить код.

mock это никак не глобальная система, какую ты себе нарисовал, это предельно простой скрипт на питоне, который ставит мини-центось (или другую fedora-based систему) в чрут и запускает в этом чруте rpmbuild --rebuild с чистым окружением, автоматически подтягивая задекларированные в spec зависимости. Всё. Вместе с ним ещё есть родственная утилита mockchain, которая собирает пакеты пачкой, публикуя заодно их все в указанный YUM-реп, так что последующие пакеты в пачке могут использовать при ребилде предыдущие. Вообще говоря, сборка rpm в mock обязательна, хотя бы финальная, для контроля воспроизводимости билда. src.rpm можно генерить с девелоперской машины, ну и вообще с любой. И mock, и mockchain скорее всего в серьёзном применении придётся патчить, они баговаты несколько, ну и просто могут не иметь каких-то определённых фич под ваши процессы, но это не будет особой проблемой, это действительно простые тулзы на питоне.

По поводу высокоуровневной системы для запуска все этого - можно попробовать билд-сервера типа TeamCity, (гугль может быть аналоги подскажет, всякие koji, obs build server, там довольно много их), но вполне естественно что они ничего не будут знать ни о семантике проекта, ни о ваших процессах, ни о существующей инфраструктуре. То есть рассчитывать со штуками типа TC можно только на то, что они умеют стягивать данные из популярных SCM, выполнять заскриптованные в конфигурации сценарии на некоторой распределённой системе билдагентов и показывать красиво результат в браузере. Всю конфигурацию всё равно придётся разрабатывать для неё самостоятельно, т.е. весь тот длинный список из ОП после слова "хочется" всё равно придётся скриптовать на каждом этапе самому, используя все те же самые знакомые тулзы.

А по поводу того, чтобы такая готовая крутая система уровня небольшого предприятия ещё и была в открытом доступе --- те же центосники, например, когда их спрашивают о конфигурации своих билд-серверов, мол, какой софт, какие процессы? заявляли, --- "Нифига, наша задача дать всем бесплатный клон RHEL, а не научить всех делать бесплатный клон RHEL.", так что я не думаю, что изначальная твоя посылка в первом предложении сильно далека от истины.

d_a ★★★★★ ()

Раз вопрос не столько про RPM, сколько про workflow, дкм пару советов: 1. Может, стоит распилить все это хозяйство по разным пакетам, а потом сделать объемлющий пакет (пусть даже пустой), который от них всех бы зависел?

2. Про интеграцию git и пакетов можно посмотреть дебиановский git-buildpackage, и утырить полезные идеи оттуда :)

undertaker ★★ ()

Плюс хочется чтобы поддерживались: ...

В Альте так по полной программе.

antares0 ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.