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

[Andrey Cherepanov]

19.03.2019 14:38, Anton Farygin пишет:
> 19.03.2019 14:28, Andrey Cherepanov пишет:
>> 19.03.2019 14:20, 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 не понравится.
>>>
>>> Мне он тоже не очень нравится - надо улучших его тем, что на каждый
>>> собранный пакет должны запускаться автоматические тесты, которые перед
>>> этим квалифицированно напишет ментейнер. Но пока нам слабо это
>>> организовать с технической точки зрения.
>>>
>> Критерии нормальности приведите, пожалуйста. Пока я увидел в обсуждении
>> критерий забывчивости. Ещё что-либо есть?
>>
> качество нашей работы - это критерий нормальности workflow.
>
> Дима в последнее время много делает для его повышения, что не может не
> радовать.

А как измерили качество нашей работы? Мне напомнить про puppetserver и
вынос systemd при обновлении из p8?

-- 
Andrey Cherepanov
cas на altlinux.org