[devel] I: gyle --test-only by default
Anton Farygin
rider на basealt.ru
Ср Мар 20 07:22:46 MSK 2019
20.03.2019 0:43, 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 такой-то устарел".
> Он в таком случае опять переедет в очередь на сборку,
> соберется, и опять вернется в очередь на коммит.
>
Это практически то, что реализовано сейчас. Только дополнительной
непрерывной пересборки не ведётся (что, в общем-то, правильно).
Подробная информация о списке рассылки Devel