[devel] git.alt build architecture

[Kirill A. Shutemov]

2009/5/18 Alexey Tourbin <at на altlinux.ru>:
> On Mon, May 18, 2009 at 11:37:37AM +0300, Kirill A. Shutemov wrote:
>> 2009/5/18 Alexey Tourbin <at на altlinux.ru>:
>> > On Mon, May 18, 2009 at 03:11:59AM +0300, Kirill A. Shutemov wrote:
>> >> Насколько я понимаю, архитектура сборки с использованием git.alt уже более-менее
>> >> устоялась. К сожалению, никакой документации описывающую эту архитектуру я не
>> >> нашёл. Может ли кто-либо из разработчиков, сделать обзор архитектуры сборочницы.
>> >> В частности, интересует какие компоненты вовлечены в процесс и как они
>> >> взаимодействуют между собой.
>> >
>> > Есть два главных компонента системы: girar и girar-builder.
>> > girar это то что обслуживает ssh доступ к git.altlinux.org.
>> > girar формирует задания для сборки.  Далее эти задания
>> > забирает на сборку girar-builder.
>> >
>> > Задание -- это каталог со специальной структурой (ближайшая аналогия --
>> > каталог /proc/$pid).  Структура каталога описана в файле
>> > girar-builder/TASK.  Описание может быть неполным или неточным,
>> > но оно дает правильное первоначальное представление.
>> >
>> > Процедура сборки задания находится girar-builder/gb-run-task.
>> > Задание состоит из нескольких стадий, которые выполняются в режиме
>> > 'sh -e' (то есть, когда одна из стадий завершается с ошибкой, остальные
>> > стадии не выполняются).  Последние стадии задания -- это копирование
>> > собранных пакетов в репозитарий и перегенерация репозитария.
>>
>> Я так понимаю, что сборка на разных архитектурах сейчас сильно связана
>> по времени. Т.е. имея одну медленную архитектуру(ARM, например), мы
>> будем тормозить сборку в целом. Даже отключение отдельных ресурсоёмких
>> проверок на медленной архитектуре не поможет, если время сборки rpm-ок
>> будет существенно отличаться.
>
> Да.  Самым ресурсоемким следует считать сборку пакетов, а girar-builder
> дает почти что константный оверхед (в районе пяти минут на задание).
> Сейчас неконстантно много ресурсов жрёт проверка с --whatprovides,
> но она будет переделана.
>
>> Возможно ли с этим что-нибудь сделать? Т.е возможно ли сделать
>> распараллеливание по архитектурам на болле высоком уровне, чем это
>> происходит сейчас, что бы сделать архитектуры менее синхронными.
>
> Я не вижу такой возможности.  Мы реализуем жесткую синхронизацию
> архитектур, и в некоторых случаях она объективно необходима (например,
> для пакетов с noarch подпакетами).  Одной из первых стадий задания
> является сборка пакетов на всех архитектурах.  Значит, пока все пакеты
> не соберутся, ничего предпринимать нельзя.

А если отодвинуть проверки, которые требуют пакеты всех собираемых
архитектур (типа проверки на идентичность noarch), на более поздний этап?
Ведь, часть проверок не требуют одновременного наличия пакетов всех
архитектур? Таким образом за счёт отключения части проверок (теста
устанавливаемости, например) на медленных архитектурах можно попробовать
частично компенсировать потерю в скорости на этапе сборки.