Создание собственных сборочных клиентов для АБФ — различия между версиями

Версия 14:47, 13 февраля 2012

Сборочный сервер

Определения

• Проект — программное обеспечение, документация, темы оформления с мета-информацией о нем, готовое для сборки и распространения в виде пакета;
• Группа — объединение пользователей для работы над совместными проектами. Позволяет управлять правами участниками сразу на нескольких проектах, принадлежащих группе.
• Платформа — набор репозиториев, представленный в системе как единое целое. Используется для выпуска разных продуктов на одной группе пакетов.
• Репозиторий — набор проектов, объединенных по определенным критериям: основные, дополнительные, несвободные и т.д.
• Продукт — собранный на базе платформы дистрибутив ОС(ISO образ).
• Обратная зависимость (back build dependence) - зависимость у пакета, обозначающая, кому для сборки нужен данный пакет
• Дерево обратных зависимостей (back build dependence tree) - дерево зависимостей, рекурсивно построенное по принципу back build dependence

Обратные зависимости

При сборки проекта необходимо пересобрать все пакеты, которые были собраны на нем ранее. Это необходимо для удовлетворения зависимостей, в случае изменения в библиотеках. Если этого не делать, то программы, собранные на старой версии библиотек, могут не работать либо работать неправильно. При построении контейнера вычисляется back build dependence tree. Например, при сборке пакета «А» вычисляется, кому он нужен для сборки, например пакетам «Б» и «С», далее вычисляется кому нужны эти пакеты для сборки и тд.
Дерево строится уровнями

1. gcc
2. tar,kernel
3. mc,firefox,mesa

Сборочный сервер собирает пакеты по уровням в несколько потоков, т.е сначала собирает 1 уровень, если сборка прошла успешно, то приступает к сборке 2 уровня и тд.
Если во время построения дерева были “петли” (пакету “А” нужен для сборки пакет “Б” , а пакету “Б” нужен “А”) то сборка будет происходить в 2 этапа: сначала соберутся все пакеты на все уровнях, далее они пересобирутся 2й раз, но с подключением результатов предыдущей сборки:

Основные компоненты

• Веб интерфейс
• Сборочное ядро
• Сборочный клиент
• Модуль сборки образов

Сборочное ядро

Служит для:

• управления сборочными клиентами
• создания/удаления платформ
• создания/удаления репозиториев
• создания/удаления сборочный заданий
• перекладывания контейнеров в репозиторий
• создания/удаления проектов
• вычисления “обратных” зависимостей для проекта (построение дерева обратных зависимостей)
• вычисления прямых зависимостей для проекта

Все команды для сборочного ядра приходят с веб интерфейса по XML-RPC
Сборочный сервер обрабатывает.выполняет запрос и отправляет результаты на веб интерфейс.
Существуют 2 типа сборочных платформ:

1. Основные платформы
2. Пользовательские платформы

Основные платформы предназначены для хранения и сборки дистрибутивов
Пользовательские платформы предназначены для хранения и сборки пользовательских проектов под разные дистрибутивы

Сборка проекта

1. С веб интерфейса приходит запрос на сборку
2. Сборочное ядро проверят возможность сборки данного проекта и добавляет задание в очередь
3. Далее сборочное задание обрабатывается, при необходимости строится список обратных зависимостей
4. Готовое сборочное задание попадает в очередь для принятия сборочными клиентами
5. При подключении сборочный клиент сообщает под какой дистрибутив он может осуществить сборку и под какие архитектуры
6. Клиент получает задание на сборку
7. После сборки с веб интерфейса приходит команда на публикацию контейнера.
8. Сборочный сервер проверяет возможность выполнения данной операции и возвращает результат на веб интерфейс. Задание помещается в очередь
9. При публикации все собранные пакеты переносятся в репозитории с учетом их принадлежности тому или иному репозиторию. При этом обновляется информация о пакетах в БД.
10. Результат переноса контейнера в репозитории отправляется на веб интерфейс

Сборочный клиент

Служит для сборки проектов. Сборочные клиенты различаются:

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

Принцип работы:

Сначала сборочный клиент забирает сборочное задание с ядра. Далее по очередности выполняется сборка каждого проекта в задании.

Порядок сборки проекта:

• Отправить статус что проект начал собираться на ядро
• Забрать из гит репозитория исходники проекта и поднять релиз в spec файле (осуществляется универсальным скриптом для rpm дистрибутивов)
• передать изменения обратно в гит и создать src.rpm
• Создать список необходимых репозиториев в зависимости от типа сборки (сборка в персональный репозиторий сборка в основной репозиторий и тд)
• Собрать проект и выложить в контейнер обновив мета-дату
• Отправить статус сборки

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

1. Построение chroot происходит в tmpfs для ускорения работы
2. Репозитории подключаются по http
3. Результаты сборки можно увидеть через веб интерфейс

Модуль сборки образов

Служит для сборки образов ОС. Представляет собой xml rpc сервер, который принимает с веб интерфейса задания на сборку дистрибутива.
В веб интерфейсе отображаются необходимые для сборки скрипты и файлы. Кроме того, есть возможность загружать архивы с дополнительными файлами требуемыми для сборки образа.
Процесс сборки:

1. С веб интерфейса приходит задание на сборку
2. Задание попадает в очередь
3. Перед началом выполнения задания на веб интерфейс отправляется статус о начале сборки
4. Скачивается архив с дополнительными файлами с веб интерфейса
5. Запускается скрипт сборки
6. После сборки отправляется результат на веб интерфейс

Подключение дополнительных дистрибутивов к сборочному серверу

Для сборки своего дистрибутива необходимо создать свой сборочный клиент и свой модуль сборки образов (изменение шаблонов. Для получения шаблонов и добавления своего дистрибутива необходимо отправить запрос на info@rosalab.ru , указав название дистрибутива.
Далее вам будет выслан архив с исходными кодами шаблонов, документация по API, руководство по изменению шаблонов и контакты инженера из ABF.
Готовый сборочный клиент и модуль сборки дистрибутива необходимо отправить инженеру ABF на аудит. После этого совместно с командой ABF производится создание инфраструктуры для вашего дистрибутива. И совместно с вами тестирование сборочного клиента и модуля сборки дистрибутива.