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

[Anton Farygin]

19.03.2019 14:15, Andrey Cherepanov пишет:
> 19.03.2019 14:11, Anton Farygin пишет:
>> 19.03.2019 14:05, Andrey Savchenko пишет:
>>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>>> изменения,
>>>>>>>>>>> осталось прежним.
>>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>>
>>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>>> ssh girar task run --commit
>>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>>
>>>>>>> При чём тут Обнинск ?
>>>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>>> нужно.
>>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>>> аргументом по-умолчанию стало больше.
>>>> Ты проверяешь локально на трёх архитектурах ?
>>> Обычно, если собралось и работает на одной, то соберётся и на
>>> остальных. --test-only нужен только при опасных изменениях,
>>> способных разнести в хлам репозиторий, например, при обновлении
>>> toolchain.
>> Ну нет, конечно если собралось на одной, то не факт что соберётся на
>> остальных.
>> А так с test-only удобнее тем, что задачи test-only не блокируемые
>> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
>> собралось (или собралось не так) гораздо раньше, чем без него - тебе
>> не надо за этим стоять в очереди на сборку.
>>
>> Ну и нормальный workflow - задание собралось на сборочнице - поставь
>> его локально, проверь и если работает - коммить.
>> а не ХХ в П, как принято у cas на .
> С чего это можно назвать нормальным workflow? По мне так ненормален.
> Сегодня произошли задержки в связи с навязыванием необоснованно глупого
> workflow.

Нет никаких сомнений, что тебе нормальный workflow не понравится.

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