On 2019-03-20 00:42:25 +0300, Dmitry V. Levin wrote:
 >> Например, в данном случае достаточно было полностью разделить
 >> два действия - build $repo $tag и commit $task - так, чтобы
 >> результатом первого являлся набор бинарных пакетов (ну, или
 >> внятная диагностика того, почему они не были собраны), а
 >> результатом второго появление этих пакетов в репозитарии.
 >> Все. Неужели это так сложно?
 > В реализации они так и разделены, но в пользовательском
 > интерфейсе такое разделение неудобно, а удобно другое: собрать
 > задание, но не коммитить vs собрать задание и закоммитить.

Неправильно. Удобно немного по-другому - когда есть возможность:
1. Собрать (build --test-only).
2. Отправить в репу собранное (сейчас для этого используется task
run, а лучше было бы сделать команду commit).
3. Собрать и попробовать отправить в репу (хорошо бы назвать это
действие build --commit).

Меня в свое время учили проектированию интерфейсов (пусть даже на
примере органов управления), ага :-) Кстати, единственный реально
существующий орган управления, выполняющий одновременно две функции -
это ручка "шаг-газ" в вертолете (да и то на ней есть корректор газа,
который делает эту связку не такой жесткой).

Еще было бы очень полезно, чтобы команда build выдавала номер
задания точно так же, как task new - в stdout. А все остальное -
соответственно, в stderr.

В общем, оптимальный по эргономике вариант видится мне примерно так:

set task=`ssh build.alt build $repo $tag`
тестируем - лопухнулись, исправляем
set task=`ssh build.alt build $repo $tag`
опять тестируем - порядок
ssh build.alt commit $task

Или, в самых простых случаях:

ssh build.alt build --commit $repo $tag


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net