[devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/15 Alexey Tourbin <at на altlinux.ru>:
>> И почему бы не включить сборку в
>> несколько потоков ?
>
> Потому что такова семантика сборки заданий: они обладают семантикой
> транзакции.  Если задание собрано успешно, то оно переводит репозитарий
> в новое состояние, и сборка следующего задания начинается уже на новом
> репозитарии.  Нельзя начинать собирать несколько заданий на старом
> репозитарии и потом "сводить" несколько результатов сборки в один новый
> репозитарий.  Это может закончиться очень плохо.

Алексей, существует ли относительно недорогой способ выяснить влияют ли
задания друг на друга после, собственно, сборки?

Идея в том, что бы запускать задания параллельно, если, по результатам
предыдущих сборок пакетов входящих в задания, есть большая вероятность,
что распараллеливание не повлияет на качество сборки. А после сборки, если
выяснилось, что задания всё же влияют друг на друга, пересобирать одно из
заданий. Если количество таких откатов будет невелико, то можно будет
получить значительный выигрыш на части заданий.

Это возможно?

На ARM есть возможность сделать сборочную ферму из большого количества
недорогого железа. Но вот без параллелизма всё грустно.