Summary: | task ls - добавить информацию о номере subtask | ||
---|---|---|---|
Product: | Infrastructure | Reporter: | Anton Farygin <rider> |
Component: | girar | Assignee: | placeholder <placeholder> |
Status: | NEW --- | QA Contact: | Andrey Cherepanov <cas> |
Severity: | enhancement | ||
Priority: | P5 | CC: | glebfm, lav, ldv, rider, vseleznv |
Version: | unspecified | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
Anton Farygin
2020-09-18 12:28:33 MSK
(Ответ для Anton Farygin на комментарий #0) > Предлагаю расширить формат вывода task ls, добавив в него номер подзадания. > Это значительно упростит операции над заданием - не надо будет отдельно > запускать show и grep для поиска номера подзадания. А зачем нужен номер подзадания? Наверное, нужен какой-то use case? Я, например, вот так пользуюсь: $ gita 2548239 delsub php7-exif а что такое gita в данном случае ? (Ответ для Anton Farygin на комментарий #2) > а что такое gita в данном случае ? $ rpm -qf /usr/bin/gita etersoft-build-utils-2.9.6-alt1.noarch Эта ошибка не о том, как с помощью внешнего инструмента получить нужное мне действие. Я хотел бы снизить количество дополнительных скриптов за счёт того, что нужный мне функционал появится на сборочнице. (Ответ для Anton Farygin на комментарий #4) > Эта ошибка не о том, как с помощью внешнего инструмента получить нужное мне > действие. Я хотел бы снизить количество дополнительных скриптов за счёт > того, что нужный мне функционал появится на сборочнице. Сборочницей всё равно нельзя пользоваться без дополнительных скриптов, у неё интерфейс для скриптов, а не человека. Саму идею сделать вывод сборочницы более удобным для скриптов поддерживаю, но мне кажется, для этого вывод должен упрощаться, а не становиться более сложным. Если же кто-то думает, что вывод сборочницы это для человека, тогда предлагаю разделить интерфейс для человека и интерфейс для робота. Они не могут быть одинаковыми. При прочих равных страдать будет человек, а не скрипты. Они не умеют. Сборочница и сама является скриптом, доступ к которому осуществляется через ssh. зачем нужно делать скрипт, который будет управлять другим скриптом, если всю необходимую функциональность можно собрать на стороне сборочницы ? (In reply to Anton Farygin from comment #6) > Сборочница и сама является скриптом Определение, что такое скрипт лежит в области философии, но мне нравится считать, что скрипт — это специализированная программа, решающая узкую задачу. Если считать так, то сборочница никак не является скриптом. (Ответ для Vladimir D. Seleznev на комментарий #7) > (In reply to Anton Farygin from comment #6) > > Сборочница и сама является скриптом > > Определение, что такое скрипт лежит в области философии, но мне нравится > считать, что скрипт — это специализированная программа, решающая узкую > задачу. Если считать так, то сборочница никак не является скриптом. Поддерживаю. Сборочница — это сервис с интерфейсом. Его можно улучшать, но язык, на котором она написана, не даёт повода ставить её на одну полку со скриптом. Но Антон приводил хороший аргумент в пользу расширения вывода task ls — это снизит количество обращений. С другой стороны, это добавление не должно ухудшить интерфейс для человека и не должно создавать дополнительную нагрузку (нулевая цена доп. функциональности). скрипт или не скрипт - не имеет значения. Важно что функционал другой специфичной программы-обвязки можно дёшево заинтегрировать в основную программу. А для роботов всё-таки действительно лучше иметь другой интерфейс. |