Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.

Все они позволяют организовать сборку программных пакетов, релиз пакетов в репозиторий и пр. Большинство систем обладают обширным функционалом, например тот же OBS позволяет собирать как deb пакеты, так и rpm, так и AppImage и т. д. Koji позволяет разбить сборку по разным машинам и управляя билдерами организовать сборку огромного числа тяжелых пакетов, многие комплексы типа OBS и Copr вообще организованы в виде сервисов в сети и позволяют различным пользователям собирать пакеты и публиковать их в публичных репозиториях.

Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?

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

Так же, что бы эту сборочницу можно было быстро доработать и т. д. Как по мне идеальный вариант для таких целей — mock. Но это утилита командной строки. Подготовка для нее исходников требуют знания, как эти исходники оформить и предоставить для сборки, а так же команды запуска сборки должны быть всегда под рукой, плюс организация хранения git для каждой сборки требует помнить, где что лежит, куда собирается, какие логи были при сборке той или иной версии пакета и т. д. Вот по этому и захотелось скрипты работы с mock объединить в один проект с графическим интерфейсом, чтоб его было не сложно поднять на локальной машине и постоянно не вспоминать какой командой подготовить исходные коды, какой командой запустить сборку и т.д.

MockGUI — это надстройка над mock по сборке пакетов и группировка их (https://github.com/bayrepo/mock-gui).

Он проще чем koji или Open Suse Build Service, но соответственно имеет и меньше функционала. Это скорее набор скриптов на ruby объединенных web-интерфейсом, под управлением Sinatra, для упорядочивания сборок из git репозиториев и управления mock.

MockGUI не требует нескольких серверов, проще разворачивается, требует меньше настроек, работает только с rpm.

Это одно пользовательская система, т. е. На текущий момент не предусмотрено разграничения прав доступа, рассчитана на работу в локальной сети без доступа извне.

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

Так же как можно было организовать хранение git репозиториев у себя в папке, потом подготовить исходники из репозитория для сборки в rpmbuild или с помощью mock и в последующем собрать с получением на выходе логов сборки и пакетов.

Так и MockGUI выполняет эти же самые действия, упорядочивает сборки, группирует их, упорядочивает логи, отображает информацию о сборках, конфигурациях, подписывает пакеты и подготавливает repoview для репозитория. Но предоставляет для этого графические формы и создает определенную структуру хранения результатов, упрощая работу разработчика (или для тех, кто привык работать с mock напрямую — усложнять работу :-)).

Есть некоторые ограничения и недостатки у системы:

Одновременно может запускаться только одна сборка.
Сборка потребляет все доступные ядра процессора (число используемых ядер может ограничиваться через make ‑j)
На текущий момент система является alpha проектом, поэтому подавление ошибок не включено, для детального отслеживания ошибок
Все проекты считаются равнозначными, поэтому система не сможет определить, что из одного проекта подключен другой с неверной архитектурой или версией ОС.
На текущий момент установка поддерживается для МСВСФера 9, AlmaLinux 9, CentOS 9 Stream и подобные системы

Внешний вид

Главный экран программы выглядит следующим образом:

Для программного комплекса присутствует документация: https://docs.brepo.ru/mockgui/

На текущий момент установка происходит из исходных кодов.

Имеется установка с помощью ansible:

sudo dnf install epel-release
sudo dnf install ansible git
git clone https://dev.brepo.ru/brepo/mock-gui.git
cd mock-gui/install
ansible-galaxy install -r requirements.yml
ansible-playbook mock-gui-install.yml --ask-become-pass
перезагрузить систему
sudo systemctl enable mockgui
sudo systemctl start mockgui

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

Необходимо будет после установки:

установить пароль на созданного пользователя: mockgui
создать gpg ключи от пользователя mockgui в его домашнем каталоге, где равзернуты исходные коды:

cd gen-scripts

./install-key UserName UserEmail 316224000 StrongSignPassword

где:

UserName - это имя владельца ключа

UserEmail - почта владельца ключа

316224000 - число секунд жизни ключа. Высчитывается по формуле: пусть нужен ключ на 2 года значит число будет: 2 366 24 60 60 = 63244800, а 316224000 = 10 лет

StrongSignPassword - пароль для ключа

Доступ к интерфейсу можно получить после успешного старта сервиса по адресу:

http://127.0.0.1:8081

Обзор возможностей

MockGUI содержит линейный список git репозиториев, которые позволяет сгруппировать в проекты.

Каждый проект является отдельным репозиторием, подписанный проект может быть доступен для использования в локальной сети или может быть опубликован с помощью rsync или scp на сервер с apache или nginx и будет доступен для скачивания и подключения в yum/dnf.

Конфигурация

Конфигурация MockGUI представлена одним файлом config.ini расположенном в корне проекта.

Пример файла конфигурации:

[server]
port = 8081
db = "sqlite://db/workbase.sqlite3"

[repo]
repo = "repo"

[projects]
path = "projects"

[counter]
path = "locks/counter"

[configs]
hide=open,amazon,anolis,circle,custom,euro,fedora,mageia,navy,alma,rocky
selected=msvsphere

[pages]
items_per_page = 30

[sign]
path = "keys"

[repoview]
path = "repoview"

Все пути указываются от корня проекта.

server

port - порт, который будет слушать сервер для доступа к WEB интерфейсу (умолчание: 8081)

db - путь к базе данных и тип базы данных (умолчание: db/workbase.sqlite3 и тип базы данных SQLite)

repo

repo - путь к каталогу, где хранятся bare git проекты, можно скопировать уже существующие, они автоматом при старте добавятся в базу (умолчание: repo)

counter

path - путь к глобальному счетчику сборок (умолчание: locks/counter)

projects

path - путь к папке, где создаются проекты, в нее же копируются git исходники, поэтому рекомендуется эту папку делать пообъемнее (умолчание: projects)

configs

hide - скрыть из списка доступных конфигураций сборки считанных из /etc/mock/, содержащие в имени одно из слов, указанных через запятую

selected - добавить в список избранных сборки с именами, указанными содержащими слова через запятую

pages

items_per_page - отображать на страницах не более указанного числа записей (умолчание: 30)

sign

path - папка, где хранятся gpg ключи (приватный и публичный) для подписи пакетов (умолчание: keys)

repoview

path - папка, где хранятся шаблоны для генерации статического repoview для подписанного репозитория (умолчание: repoview)

Так же следует учесть, что сборки происходят в папке /var/lib/mock поэтому данная папка так же должна быть большого объема.

Управление git репозиториями

По умолчанию git проекты - это папки содержащие bare git структуры, которые расположены в каталоге repo (настраивается в конфигурации).

Папка repo может содержать не зарегистрированные git репозитории, в таком случае они при открытии страницы автоматически добавятся в базу (правда без описания).

Просмотр информации git репозитория - на текущий момент есть возможность просмотра:

Списка веток
Списка коммитов
Списка тегов
Строки для клонирования репозитория
Описание репозитория

Список тегов и коммитов даст информацию о том, что исходные коды в ветке master находятся в нужном состоянии и с нужными коммитами. Сборочница производит выборку исходных кодов из master ветки git репозитория.

Для успешного клонирования и наполнения git репозитория, необходимо либо установить публичный ключ для доступа пользователя по ssh или знать пароль к mockgui пользователю по ssh.

Вот почему при установке MockGUI рекомендуется установить пароль для mockgui пользователя.

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

При нажатии на кнопку "Удалить" появится окно, где нужно будет написать имя репозитория и нажать кнопку "Удалить" для подтверждения удаления.

Сценарии подготовки исходных кодов git репозиториев

Сценарии подготовки исходных кодов git репозиториев в дальнейшем буду называть рецептами.

Для сборки необходимо, чтоб все файлы git проекта были прописаны в spec файле, а зачастую в spec файле файлы исходных кодов прописаны как один архив.

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

Но если необходимо проделать какие-то манипуляции для подготовки исходных файлов, то сборка завершится с ошибкой.

Чтоб не было ошибки для этого сделаны рецепты.

Рецепт - это по сути bash скрипт, который:

получает на вход spec файл
парсит spec файл при необходимости
делает необходимые манипуляции с исходными кодами
производит подготовку к сборке

Нужно учитывать при написании сценариев, что они выполняются в реальной системе, поэтому их функционал ограничен теми утилитами, которые установлены в ОС. Например это может быть:

использование sed, grep для создания файлов конфигураций
использование доступных архиваторов в системе для подготовки архива
и т.д.

Пример такого скрипта уже встроен в MockGUI - make_tar_from_git. Он из исходных кодов git проекта создает архив для сборки:

#!/bin/bash

need_spec="n"
SPEC="$1"
FIND_SPEC="$SPEC"
if [ -z "$SPEC" ];then
    need_spec="y"
fi
if [ -n "$SPEC" -a ! -e "$SPEC" ];then
    need_spec="y"
fi
if [ "$need_spec" == "y" ];then
    FIND_SPEC=$(/usr/bin/find . -iname "*.spec" -type f -print -quit)
fi
if [ -n "$FIND_SPEC" ];then
    NAME=$(rpm -q --queryformat="%{NAME}" --specfile "$FIND_SPEC" | xargs)
    VERSION=$(rpm -q --queryformat="%{VERSION}" --specfile "$FIND_SPEC" | xargs)
    PKG_NAME="${NAME}-${VERSION}"
    tar -h --exclude="${PKG_NAME}.tar.gz" --exclude=".git" --exclude="$FIND_SPEC" -cvf ${PKG_NAME}.tar.gz --transform "s,^,${PKG_NAME}/," *
    exit 0
else
    echo "Не найден spec файл"
    exit 255
fi

Его код прост, скрипт выполняется в корне git репозитория, он получает spec файл, извлекает из него версию и имя пакета и создает тут же архив. Данные рецепты могут изменять исходники, это не вредит репозиторию, т.к все манипуляции делаются с копией данных во временном каталоге.

Рецепты можно создавать, модифицировать и привязывать к git репозиториям. Они будут автоматически вызваны, при сборке git репозитория в каком либо проекте.

Один рецепт может быть привязан ко множеству git проектов.

Окружения сборки mock

Отображает список доступных окружений, отфильтрованных согласно конфигурации

Файлы конфигурации доступны только для ознакомления.

Добавлять можно только вручную, редактируя файлы по пути /etc/mock/

Список конфигураций:

Рисунок 4. Пример списка конфигураций сборки.

В листинге - файл конфигурации сборки можно кликнуть мышкой на include и будет происходить переход на указанный шаблон или конфигурацию, что весьма помогает при изучении конфигурации.

Конфигурация сборки необходима при создании проекта.

Управление проектами

Проекты - это объединения git репозиториев, результат которого - это репозиторий rpm пакетов (подписанный и не подписанный).

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

Подписанный репозиторий используется для публикации rpm пакетов на внешний сервер (внешний репозиторий).

Для создания нового проекта, необходимо перейти на вкладку «Проекты» и нажать на плюс «+».

Название проекта - уникальное название проекта, оно будет содержаться в названии будущего репозитория, поэтому стоит подходить к названию с умом.
Описание - краткое описание
Не публиковать отладочные пакеты и исходные коды - при установленном флажке в подписанный репозиторий не публикуются пакеты src.rpm, debuginfo, debugsource. Если флажок не установлен, то подписывается и публикуется все. Флажок для ПО чьи исходные коды или отладочные пакеты не должны публиковаться.
Выберите конфигурацию окружения сборки для проекта - выбирается конфигурация сборки, выбирается один раз при создании проекта и больше потом не меняется. Можно только создать новый проект с другой конфигурацией.

Пример выбора конфигурации. Имеется поле фильтрации:

Рисунок 6. Пример выбора окружения сборки

После создания, проект становится доступен в списке проектов. Можно перейти на страницу получения информации о проекте.

На данной странице можно:

Посмотреть список git репозиториев, которые включены в проект (по каждому репозиторию можно — «корзина»: удалить git репозиторий из проекта (но ранее собранные пакеты из этого проекта останутся в rpm репозитории), «play»: запустить сборку пакетов из репозитория, «стрелка в квадрате» - указать, какой спек файл использовать при сборке, «стена» - отобразить все сборки для данного git репозитория и текущего проекта.

Редактировать конфигурацию сборки — для каждого проекта создается свой файл конфигурации окружения mock. Здесь включаются необходимы настройки для проекта, могут быть подключены зависимые проекты. И вот эту конфигурацию редактировать можно. Можно, для примера, прописать какой-то свой репозиторий и т. д.

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

Список всех пакетов (не подписанных). Здесь можно получить информацию о rpm пакетах, changelog, списке зависимостей и файлах в пакете.

Список сборок проекта — отображаются все сборки для проекта и информация о них.

Подписать — подписать все ранее собранные и не подписанные пакеты и положить их в signed репозиторий.

Просмотр подписанного репозитория — вот здесь можно посмотреть как репозиторий будет выглядеть при переносе на публичный сервер. При подписывании в signed репозитории создается repoview файл с информацией о пакетах.

Установить адрес удаленного репозитория — данный адрес нужен для корректного формирования шапки в repoview файле. Чтоб указывался правильный url к пакетом, когда они будут rsync-ом перенесены в публичный репозиторий.

Пример repoview:

Если git проект обновился, т.е в него были отправлены новые изменения, то напротив git репозитория в проекте появляется значок «круговые стрелки», что означает, что исходные коды в проекте нужно обновить. Т.е нажать на стрелочки и тогда они исчезнут.

В принципе все, что хотелось бы рассказать о данном проекте.

Всю дополнительную информацию можно найти в документации и исходных кодах проекта.

Спасибо за внимание!

MockGUI – помощь в сборке и организации мини репозитория rpm пакетов