[devel] Сборочница. VI. Гибкость и настраиваемость.

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Уважаемые господа!

Продолжаю цикл писем, посвященный предложениям по улучшению
нашей сборочницы.

VI. Гибкость и настраиваемость.

Нашей сборочнице не хватает гибкости и настраиваемости.
Есть только режим работы по умолчанию и --test-only.

Зачем нашей песочнице гибкость и настраиваемость?

Во-первых, чтобы решать с ее помощью больше задач.

Что хочу предложить:

A) Опция --force-tests. Выполнить все возможные тесты.

Настройка, которую легко добавить в сборочницу
и которая очень полезна для подготовки больших транзакций.

К примеру, готовлю major обновление, со сменой библиотеки, к примеру perl. 
Если я отправлю на сборку perl с минимальной обвязкой,
то сборочница соберет пакеты и остановится на unmets.
А я и так знаю, что perl с минимальной обвязкой не пройдет unmets тест.
Мне хочется заранее протестировать новую сборку всеми имеющимися
в сборочнице тестами, перед тем, как создать большую транзакцию.
Если --force-tests, то я узнаю, что в самой сборке perl проблем нет
или выявлю проблемы заранее.

У нас же я должен подготовить большую транзакцию,
собирать ее три дня и три ночи, и в конце узнать, что проблемы были
в сборке perl.

Другой пример для --force-tests -- пакет не собирается на одной из
архитектур сборочницы (скажем, на arm).
Но хочется узнать результаты всех тестов, вплоть до symbols,
хотя бы на x86_64, чтобы сразу готовить все нужные исправления.

Б) Опции для гибкой настройки hasher'а.
что-то вроде
set <task> [<subtask>] wlimit_time_elapsed <val>
set <task> [<subtask>] wlimit_time_idle <val>
set <task> [<subtask>] wlimit_bytes_written <val>

1) Бывают ситуации, когда стоит уменьшить wlimit_* до нескольких минут,
например, при отладке зависающей сборки.

2) иногда текущее умолчание просто недостаточно, чтобы пакет собрался:
https://bugzilla.altlinux.org/show_bug.cgi?id=31683
Bug 31683 - big packages: an option to adjust hasher-priv time elapsed limit in task run

В) возможность указать адрес для сообщений (при проблемах с email)

ssh git.alt task run --email <mail addr> option
https://bugzilla.altlinux.org/show_bug.cgi?id=27637

Г) возможность выбрать оптимальный для конкретной задачи алгоритм тестирования.

Последний пункт навеян моим горьким опытом.

Я хотел бы собрать обновление texlive так, как texlive собирается
апстримом, т.е. в виде большого числа (6000+, 3000 исходных) пакетов.
Но было ощущение, что такую транзакцию за осмысленное время
в нашей сборочнице не собрать.

Игорь Зубков тогда привел пример
> А самой кровавой пересборкой был python2.6 -> python2.7. Там было
> больше 2000 пакетов. Наверно месяц пересобирали. :)

По аналогии с python, для ее обработки понадобилась бы минимум полтора месяца.
Поэтому я сосредоточился на компромиссном варианте,
допилить импортированный пакет из Fedora, где все 6000+ пакетов
собирались из одного srpm. После долгих и упорных оптимизаций,
мне удалось добиться, что сборка пакета проходила всего за 1 час.
по техническим причинам (баги в rpmbuild на 2Gb) его еще пришлось
аккуратно разделить на 2 меньших пакета.

Пропущу ненужные детали. В итоге я первый раз залил транзакцию
с texlive в сборочницу, и тут меня ждал большой сюрприз:
да, сборка прошла за час, но потом сборочница больше 10 суток
тестировала пакеты на устанавливаемость.

Как можно сопровождать пакет, если каждое малейшее его обновление
будет обрабатываться нашей сборочницей по 10 суток?

В итоге, с текущей сборочницей, мне пришлось отказаться
от этого варианта сборки texlive.

Сюрприз же заключался в том, то в моей сборочнице один из пакетов,
texlive-doc (2500+ подпакетов) прошел install тест менее чем за
два часа. Я не тестировал полную транзакцию, но ожидал, что
сборочнице нужно будет не более 4-5 часов вместо 10 суток.

Разница оказалась в алгоритмах. У Дмитрия сборочница тестировала
установку пакета в минимальный chroot, у меня - в общий chroot.

Это, вообще говоря, два разных теста. У них есть общее подмножество
багов, которые они выявляют - некорректные скрипты и конфликтующие
пакеты в зависимостях, но есть и свои, уникальные для каждого
теста выявляемые баги. Первый гарантированно выявляет скрипты,
не подкрепленные зависимостями. Второй - неявные конфликты между
подпакетами и вообще пакетами в транзакции.

Первый выявляет тяжело другими способами выявляемые баги,
но для пакетов с %post/un скриптами, которые становятся уже редкостью,
вытесняемые файлтриггерами, и крайне медленный.
Второй гораздо быстрее, ловит свои баги, которые не ловит первый тест,
но не ловит те редкие баги, для которых писался первый тест.

Какой из них лучше? Перфекционист сказал бы - дайте два.
Действительно, если бы в сборочнице был бы выбор, то можно было бы
при мажорных изменениях прогонять пакет через медленный тест,
а при тривиальных - через быстрый, при чем заодно проверить на наличие
бОльшего числа багов, чем если бы использовался только один тест.

При больших транзакциях, таких как упомянутая ранее пересборка python,
Прогоняя новую версию питона через медленный тест с --force-tests,
и включая быстрый тест на всю пересборочную транзакцию,
даже в нынешней сборочнице удалось бы ту же транзакцию с питоном
собрать на 15 суток раньше.

-- 

I V