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

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Обратные зависимости)
 
(не показано 13 промежуточных версий 2 участников)
Строка 1: Строка 1:
 +
[[Категория:Сборочная среда ABF]]
 
== Сборочный сервер ==
 
== Сборочный сервер ==
  
Строка 9: Строка 10:
 
*'''Обратная зависимость''' (''back build dependence'') - зависимость у пакета, обозначающая, кому для сборки нужен данный пакет
 
*'''Обратная зависимость''' (''back build dependence'') - зависимость у пакета, обозначающая, кому для сборки нужен данный пакет
 
*'''Дерево обратных зависимостей''' (''back build dependence tree'') - дерево зависимостей, рекурсивно построенное по принципу ''back build dependence''
 
*'''Дерево обратных зависимостей''' (''back build dependence tree'') - дерево зависимостей, рекурсивно построенное по принципу ''back build dependence''
 
== Обратные зависимости ==
 
При сборки  проекта необходимо пересобрать все пакеты, которые были собраны на нем ранее. Это необходимо для удовлетворения зависимостей, в случае изменения в библиотеках. Если этого не делать, то программы, собранные на старой версии библиотек, могут не работать либо работать неправильно. При построении контейнера вычисляется ''back build dependence tree''. Например, при сборке пакета «А» вычисляется, кому он нужен для сборки, например пакетам «Б» и «С», далее вычисляется кому нужны эти пакеты для сборки и тд.<br/>
 
Дерево строится уровнями
 
#gcc
 
#tar,kernel
 
#mc,firefox,mesa
 
 
Сборочный сервер собирает пакеты по уровням в несколько потоков, т.е сначала собирает 1 уровень, если сборка прошла успешно, то приступает к сборке 2 уровня и тд.<br/>
 
Если во время построения дерева были “петли” (пакету “А” нужен для сборки  пакет “Б” , а пакету “Б” нужен “А”) то сборка будет происходить в 2 этапа: сначала соберутся все пакеты на все уровнях, далее они пересобирутся 2й раз, но с подключением результатов предыдущей сборки:
 
[[File:Bbdt.jpg|none|thumb]]
 
  
 
=== Основные компоненты ===
 
=== Основные компоненты ===
Строка 27: Строка 17:
 
*Модуль сборки образов
 
*Модуль сборки образов
  
[[File:SqUiMvkpq_lbw8D4twm3cRQ.png|none|thumb]]
+
[[File:SqUiMvkpq_lbw8D4twm3cRQ.png|center|400px]]
  
 
== Сборочное ядро ==
 
== Сборочное ядро ==
Строка 39: Строка 29:
 
*вычисления “обратных” зависимостей для проекта (построение дерева обратных зависимостей)
 
*вычисления “обратных” зависимостей для проекта (построение дерева обратных зависимостей)
 
*вычисления прямых зависимостей для проекта
 
*вычисления прямых зависимостей для проекта
 
 
 
Все команды для сборочного ядра приходят с веб интерфейса по XML-RPC<br/>
 
Все команды для сборочного ядра приходят с веб интерфейса по XML-RPC<br/>
 
Сборочный сервер обрабатывает.выполняет запрос и отправляет результаты на веб интерфейс. <br/>
 
Сборочный сервер обрабатывает.выполняет запрос и отправляет результаты на веб интерфейс. <br/>
Строка 47: Строка 35:
 
#Пользовательские платформы
 
#Пользовательские платформы
  
'''Основные платформы''' предназначены для хранения и сборки дистрибутивов<br/>
+
''Основные платформы'' предназначены для хранения и сборки дистрибутивов<br/>
'''Персональные платформы''' предназначены для  хранения и сборки пользовательских проектов под разные дистрибутивы<br/>
+
''Пользовательские платформы'' предназначены для  хранения и сборки пользовательских проектов под разные дистрибутивы<br/>
 
=== Сборка проекта ===
 
=== Сборка проекта ===
 
#С веб интерфейса приходит запрос на сборку
 
#С веб интерфейса приходит запрос на сборку
Строка 64: Строка 52:
 
Служит для сборки проектов.  
 
Служит для сборки проектов.  
 
Сборочные клиенты различаются:
 
Сборочные клиенты различаются:
по поддерживаемым сборочным архитектурам. Под какие архитектуры сборочный клиент может собрать проект  
+
*по поддерживаемым сборочным архитектурам. Под какие архитектуры сборочный клиент может собрать проект  
по типам дистрибутива под которые данный сборочный клиент может собрать проект
+
*по типам дистрибутива, под которые данный сборочный клиент может собрать проект
  
  
Принцип работы:
+
'''Принцип работы:'''
Сначала сборочный клиент забирает сборочное задание с ядра. Далее по очередности выполняется сборка каждого проекта в задании.
+
: Сначала сборочный клиент забирает сборочное задание с ядра. Далее по очередности выполняется сборка каждого проекта в задании.
Порядок сборки проекта:
+
'''Порядок сборки проекта:'''
Отправить статус что проект начал собираться на ядро
+
*Отправить статус что проект начал собираться на ядро
Забрать из гит репозитория исходники проекта и поднять релиз в spec файле (осуществляется универсальным скриптом для rpm дистрибутивов)
+
*Забрать из гит репозитория исходники проекта и поднять релиз в spec файле (осуществляется универсальным скриптом для rpm дистрибутивов)
передать изменения обратно в гит и создать src.rpm
+
*передать изменения обратно в гит и создать src.rpm
Создать список необходимых репозиториев в зависимости от типа сборки (сборка в персональный репозиторий сборка в основной репозиторий и тд)
+
*Создать список необходимых репозиториев в зависимости от типа сборки (сборка в персональный репозиторий сборка в основной репозиторий и тд)
Собрать проект и выложить в контейнер обновив мета-дату
+
*Собрать проект и выложить в контейнер обновив мета-дату
Отправить статус сборки
+
*Отправить статус сборки
 
+
Если присутствуют циклические зависимости сборка происходит повторно с подключением предыдущих результатов
+
После сборки всех проектов происходит автоматическое тестирование результатов сборки. Оно представляет собой попытку установки всех пакетов в chroot . проверка нужна для контроля зависимостей у собранных пакетов
+
 
+
После сборки всех проектов и автоматического тестирования отправляется , результаты отправляются на сборочное ядро
+
Построение chroot происходит в tmpf для ускорения работы
+
Репозитории подключаются по http
+
Результаты сборки можно увидеть через веб интерфейс
+
 
+
  
 +
Если присутствуют циклические зависимости, сборка происходит повторно с подключением предыдущих результатов<br/>
 +
После сборки всех проектов происходит автоматическое тестирование результатов сборки. Оно представляет собой попытку установки всех пакетов в chroot. Проверка нужна для контроля зависимостей у собранных пакетов<br/>
 +
После сборки всех проектов и автоматического тестирования результаты отправляются на сборочное ядро
 +
#Построение chroot происходит в tmpfs для ускорения работы
 +
#Репозитории подключаются по http
 +
#Результаты сборки можно увидеть через веб интерфейс
  
 
== Модуль сборки образов ==
 
== Модуль сборки образов ==
Служит для сборки образов ОС. Представляет собой xml rpc сервер, который принимает с веб интерфейса задания на сборку дистрибутива.  
+
Служит для сборки образов ОС. Представляет собой xml rpc сервер, который принимает с веб интерфейса задания на сборку дистрибутива.<br/>
 +
В веб интерфейсе отображаются необходимые для сборки скрипты и файлы. Кроме того, есть возможность загружать  архивы с дополнительными файлами требуемыми для сборки образа.<br/>
 +
'''Процесс сборки:'''
 +
#С веб интерфейса приходит задание на сборку
 +
#Задание попадает в очередь
 +
#Перед началом выполнения задания на веб интерфейс отправляется статус о начале сборки
 +
#Скачивается архив с дополнительными файлами с веб интерфейса
 +
#Запускается скрипт сборки
 +
#После сборки отправляется результат на веб интерфейс
  
В веб интерфейсе отображаются необходимые для сборки скрипты и файлы. кроме того есть возможность загружать  архивы с дополнительными файлами требуемыми для сборки образа.
+
== Подключение дополнительных дистрибутивов к сборочному серверу ==
Процесс сборки:
+
С веб интерфейса приходит задание на сборку
+
Задание попадает в очередь
+
Перед началом выполнения задания на веб интерфейс отправляется статус о начале сборки
+
Скачивается архив с дополнительными файлами с веб интерфейса
+
Запускается скрипт сборки
+
После сборки отправляется результат на веб интерфейс
+
  
 +
Для сборки своего дистрибутива необходимо создать свой сборочный клиент и свой модуль сборки образов (изменение шаблонов. Для получения шаблонов и добавления своего дистрибутива необходимо отправить запрос на [mailto:info@rosalab.ru info@rosalab.ru] , указав название дистрибутива.<br/>
 +
Далее вам будет выслан архив с исходными кодами шаблонов, документация по API, руководство по изменению шаблонов и контакты инженера из ABF.<br/>
 +
Готовый сборочный клиент и модуль сборки дистрибутива необходимо отправить инженеру ABF на аудит. После этого совместно с командой ABF производится  создание инфраструктуры для вашего дистрибутива. И совместно с вами тестирование сборочного клиента и модуля сборки дистрибутива.
  
  
 +
{{Навигационная полоса|Документация по теме «Сборочная среда ABF»|[[Сборочная среда ABF]]&nbsp;&#8226;&nbsp;[[Краткое руководство по работе в сборочной среде ABF]]&nbsp;&#8226;&nbsp;[[ABF: Руководство пользователя]]&nbsp;&#8226;&nbsp;[[ABF: Руководство администратора]]}}
  
== Подключение дополнительных дистрибутивов к сборочному серверу ==
+
[[En:Creating ABF build bots]]
 
+
Для сборки своего дистрибутива необходимо создать свой сборочный клиент и свой модуль сборки образов (изменение шаблонов).Для получения шаблонов и добавления своего дистрибутива необходимо отправить запрос на info@rosalab.ru , указав название дистрибутива.
+
Далее вам будет выслан архив с исходными кодами шаблонов, документация по API, руководство по изменению шаблонов и контакты инженера из ABF.
+
Готовый сборочный клиент и модуль сборки дистрибутива необходимо отправить инженеру ABF на аудит. После этого совместно с командой ABF производится  создание инфраструктуры для вашего дистрибутива. И совместно с вами тестирование сборочного клиента и модуля сборки дистрибутива
+

Текущая версия на 14:59, 3 марта 2014

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

Определения

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

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

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

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

Служит для:

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

Все команды для сборочного ядра приходят с веб интерфейса по 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 производится создание инфраструктуры для вашего дистрибутива. И совместно с вами тестирование сборочного клиента и модуля сборки дистрибутива.


Документация по теме «Сборочная среда ABF»