[devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 12:25:51AM +0300, Anton Farygin wrote:
> 20.03.2019 0:05, Igor Vlasenko пишет:
> > On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
> > > Например, в данном случае достаточно было полностью разделить два
> > > действия - build $repo $tag и commit $task - так, чтобы результатом
> > > первого являлся набор бинарных пакетов (ну, или внятная диагностика
> > > того, почему они не были собраны), а результатом второго появление
> > > этих пакетов в репозитарии. Все. Неужели это так сложно?
> > Более того, за счет разделения build и commit
> > можно было бы существенно ускорить сборочницу.
> > Ведь build можно делать параллельно,
> > а commit приходится делать последовательно.
> > 
> > Но если build и commit отдельно,
> > и очереди на build и commit отдельно.
> > то commit можно делать крупными кусками.
> > залил таски 300001 ... 300010 в очередь на build,
> > собрались таски.
> > 
> > И забросил в очередь на commit
> > не 10 команд COMMIT 300001, ... COMMIT 300010
> > а команду COMMIT 300001, ..., 300010 -
> > выполнится в 10 раз быстрее.
> > 
> > А в идеале умная сборчница сама будет это делать.
> > 
> Вы забываете, что некоторые build требуют rebuild других тасков при commit.

Так некорректно говорить,
"некоторые build требуют rebuild других тасков"
имеет смысл только в контексте конкретной реализации.

Если в сборочнице будут две очереди, на build и на commit,
то реализация будет другой и
такой случай будет называться по другому:
"собранный task такой-то устарел".
Он в таком случае опять переедет в очередь на сборку,
соберется, и опять вернется в очередь на коммит.

Проверку на устаревание и последующий уход
на повторную пересборку можно запускать 
параллельно и независимо от commit.

Все это можно делать автоматически,
информируя майнтайнера только изменением статуса таска.

-- 

I V