Difference between revisions of "Creating ABF build bots"

Revision as of 11:16, 13 April 2012

Build Server

Terms and Definitions

• Project — software source code, documentation and other artifacts accompanied by meta-information necessary to build and distribute the software product as a package.
• Group — users working on the same project. ABF allows to manage access privileges on both per-user and per-group levels.
• Platform — a group of repositories to be handled as a single entity. Such groupings are useful for creating different products from the same set of packages.
• Repository — a set of packages grouped together according to certain criteria: main packages, auxiliary packages, non-free software, etc.
• Product — ISO image of a distribution built on the basis of some platform.
• Reverse dependency — a package that requires the current one; "reverse build dependency" stands for a dependency necessary for building a package

Reverse dependencies

After building a package, one should normally rebuild all packages that depend on it (for example, to pick up library changes). In many cases packages built with older version can work incorrectly or fail to work at all with the new version. ABF is able to perform such rebuild automatically. In order to do this, it iteratively calculates reverse build dependency tree of the package being built. That is, it takes package "A", detects that it is required to build packages "B" and "C", then calculates reverse dependencies of "B" and "C" and so on, until a closure set is obtained.
The tree is built using width-first search algorithm

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

Build server builds packages level by level in multiple threads - that is, a package from some level will be built only when all packages from higher levels are already rebuilt successfully.
If loops are detected when calculating dependency tree (i.e., "A" requires "B" and "B" requires "A"), then the rebuild process will be performed twice: first, all packages on all tree levels will be build, and then they will be rebuilt using results from the first stage:

Main components

• Web UI
• Build core
• Build client (bot)
• ISO generation module

Build core

Responsible for:

• management of build clients (bots)
• creation/removal of platforms
• creation/removal of repositories
• creation/removal of build tasks
• publishing containers into repository
• creation/removal of projects
• calculation of reverse dependencies for the project
• calculation of direct dependencies for the project

The build core receives commands from Web UI using XML-RPC
Build server processes these requests and sends result back to WebUI

There are 2 kinds of platforms in ABF:

1. Main platforms
2. User platforms

Main platforms are supposed to build and maintain the whole distributions
User platforms are intended for building and maintaining user projects that can be built for different distributions

Project build workflow

1. WebUI sends a build request
2. Build core checks if the requested project can be built and puts appropriate task in the queue
3. The task is processed, reverse dependency tree is built, if necessary
4. Build task is formed for the build client; this task is put in the clients' queue
   • When connecting to the build server, every client reports for which distributions and hardware architectures it can build packages
5. A client receives the build task and processes it
6. When package is built, one can use WebUI to send a request on publishing the resulting container
7. Build server checks if it possible to publish the container puts appropriate task in the queue
8. During publishing all built packages are moved to repositories they belong to. The ABF database storing information about packages is updated.
9. WebUI is informed that container is published.

Build client (bot)

Client is used to build packages. Build clients can differ in the following ways:

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

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

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

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

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

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

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

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

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

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

Adding support for more distributions

If you want to build your own distribution using ABF you should develop corresponding build client and ISO generation module. In order to do this, you can use existing templates. If you want to add support for your distribution in the main ABF instance, please send a request to info@rosalab.ru. You will be provided with necessary help, templates, documentation, etc. When your build client and ISO generator are ready you should send them to ABF developers for review. If everything is ok, ABF team will help to integrate the new stuff into the main ABF instance.