Re: [devel] Задачи для сборочницы следующего поколения

[Leonid Krivoshein <klark.devel@gmail.com>]

Можно тут рядышком постоять? Иначе для чего ещё эта рассылка...


16.02.2018 04:33, Dmitry V. Levin пишет:
> Предлагаю начинать разговор не с алгоритмов оптимизации сборочницы,
> а с задач, которые мы хотим решать с помощью сборочной системы
> следующего поколения.
>
> ...
>
> Одна из задач, которую мы хотели решать ещё 9 лет назад - оперативно
> выявлять регрессии собираемости/устанавливаемости пакетов репозитория
> и на этом основании (полу)автоматически принимать решения об окончательном
> коммите транзакций.

Правильно понимаю, что полуавтоматическое принятие решения позволяет, в 
числе прочего, условно модератору репозитория откатывать мержи вручную? 
Если да, то какова (обычно) судьба всех последующих мержей, следующих за 
выкинутым(и)?

> Мы хотим не только автоматически выявлять анметы, порождаемые транзакцией,
> но и...
> Наша традиционная сборочная система обладает следующим полезным свойством:
> каждое следующее состояние репозитория получается в результате применения
> транзакции к предыдущему состоянию.
>
> Такой детерминизм позволяет воспроизводимо получать новое состояние
> репозитория из старого путём последовательного применения транзакций.
>

Для разработчиков, госадминов и регуляторов большой интерес представляет 
репозиторий с исходниками (git, .src.rpm). Для большинства конечных 
пользователей куда важнее работоспособность производного -- бинарного 
репозитория. Очень хорошо, что сборочница позволяет автоматически 
выявлять и пресекать многие проблемы "на подлёте". Но мы же понимаем, 
что выявить все проблемы автоматически нельзя. И со всеми успешно 
прошедшими тестами, случается, возникают регрессии, больше проявляющиеся 
даже не в части сборки/установки, а уже в процессе эксплуатации.

Конечно важно мерило, определяющее качество исходного репозитория, в 
целом, полученного в результате очередной (мега) транзакции. Но также 
важно иметь возможность отката отдельных изменений с автоматическим 
применением последующих изменений. Тогда фаза тестирования может 
отставать (то бишь не быть тормозящим фактором), но при необходимости, 
бить по мержу вдогонку. А все последующие (мега) транзакции в случае 
такого фейла могут быть объединены в ещё более крупную супер-(мега) 
транзакцию.

> К чему привело бы применение нескольких транзакций одновременно?  В общем
> случае к тому, что результат применения отличался бы от результата
> последовательного применения.  Не лучше ли вместо этого (спекулятивно)
> объединять множество транзакций, готовых к применению, в полноценные
> мега-транзакции, обрабатываемые как обычные транзакции?

Если одна обычная транзакция -- изменения репозитория в результате 
одобрения задания из одного и более исходных пакетов, то мега-транзакция 
-- это, если не весь репозиторий, то, по крайней мере, оба графа 
зависимостей с каждым из пакетов накопившихся к текущему моменту заданий 
(сборочными и установочными), верно?

Мне кажется, если преодолеть зависимость мержа от предыдущего мержа не в 
ущерб воспроизводимой сборке, мы как раз-таки получим параллельную 
сборочницу нового поколения. Очерёдность безусловно важна. Но ведь если 
кому-то в очереди становится плохо, очередь от этого не аннулируется.

Можно гонять сборочницу несколько раз в сутки по всем необходимым 
пакетам по мере их поступления, но публиковать только те состояния 
репозитория, при которых мерило показывает приемлемый результат. То есть 
мега-транзакция может допускать фейлы отдельных пакетов. Но такое 
состояние не публикуется, а учитывается на следующих кругах.


-- 
Best regards,
Leonid Krivoshein.