27637 2012-08-13 15:22:01 +0400 ssh git.alt task run --email <mail addr> option 2021-06-21 01:53:46 +0300 1 1 2 Infrastructure Infrastructure girar unspecified all Linux NEW P3 enhancement --- 1 viy placeholder glebfm ldv mithraen cas oldest_to_newest 132769 0 viy 2012-08-13 15:22:01 +0400 Добавьте, пожалуйста, опцию --email <mail addr> к git.alt task run. Опция нужна для роботов типа cronbuild, которые формируют задания по поручению других пользователей, а также полезна и майнтайнеру, когда у него временные проблемы с почтовым ящиком. $ ssh git.alt task run --email tmp_mbox@mail.com task #77471: try #1 is AWAITING, result will be emailed to tmp_mbox@mail.com 132962 1 viy 2012-08-24 12:58:32 +0400 важно для cornbuild/corncopy/cronport 133677 2 viy 2012-10-04 12:48:17 +0400 На всякий случай еще раз напоминаю про опцию --email <mail addr> к git.alt task run. Я хотел бы автоматизировать администрирование сервисами типа cronbuild, которые формируют задания по поручению других пользователей, и для этого такая опция очень нужна. $ ssh git.alt task run --email tmp_mbox@mail.com task #77471: try #1 is AWAITING, result will be emailed to tmp_mbox@mail.com 136548 3 mithraen 2013-01-02 06:53:06 +0400 Вот сегодня опять была проблема -- один из моих моих пакетов, который поддерживается cronbuild почему-то не собрался (task #87283). Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил, а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты). 136619 4 ldv 2013-01-06 18:09:50 +0400 (In reply to comment #3) > Вот сегодня опять была проблема -- один из моих моих пакетов, который > поддерживается cronbuild почему-то не собрался (task #87283). > > Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил, > а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты). Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы иметь возможность выставлять заданию свойство отправлять уведомления в соответствии с ACL собираемых пакетов не только при успешной сборке, но и при неудаче на более ранних стадиях обработки задания. 136629 5 viy 2013-01-06 21:35:53 +0400 (В ответ на комментарий №4) > Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы > иметь возможность выставлять заданию свойство отправлять уведомления в > соответствии с ACL собираемых пакетов не только при успешной сборке, но и при > неудаче на более ранних стадиях обработки задания. А почему бы не сделать сразу два варианта? и грубый --<явно указать кому> и более специальный - "отправлять уведомления в соответствии с ACL ..." Ведь только второго варианта недостаточно - с ним при желании не отключишь отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075 сборок, это 2075 spam messages. Один универсальный инструмент в природе редко встречается. Кому-то молоток нужен, а кому-то топор. Скрещивать их в микроскоп не нужно. С наступающим Рождеством! 136630 6 ldv 2013-01-06 21:56:02 +0400 (In reply to comment #5) > (В ответ на комментарий №4) > > Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы > > иметь возможность выставлять заданию свойство отправлять уведомления в > > соответствии с ACL собираемых пакетов не только при успешной сборке, но и при > > неудаче на более ранних стадиях обработки задания. > > А почему бы не сделать сразу два варианта? и грубый --<явно указать кому> Дело в том, что cronbuild не может точно знать, кому. Он только знает, кто ему дал задание, и все. Есть ли случаи, когда достаточно отправлять уведомления только своему инструктору вместо всех членов ACL? > и более специальный - "отправлять уведомления в соответствии с ACL ..." > Ведь только второго варианта недостаточно - с ним при желании не отключишь > отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075 > сборок, это 2075 spam messages. Флажок "не отправлять уведомления мне" тоже может быть полезен. 136632 7 viy 2013-01-06 22:24:02 +0400 (В ответ на комментарий №6) > (In reply to comment #5) > Дело в том, что cronbuild не может точно знать, кому. Он только знает, кто ему > дал задание, и все. Есть ли случаи, когда достаточно отправлять уведомления > только своему инструктору вместо всех членов ACL? Вроде бы пока все случаи только такие. Если возникнет прецедент, то можно будет сдеать объезд в самом cronbuild, ему можно будет добавить в cronbuild переменную, где хранить список аргументов для --<обсуждаемой опции> и тот кто заказал пакет, может настроить в пакете явную рассылку. при условии, что в --<обсуждаемой опции> будет поддержка нескольких указаний опции или нескольких аргументов. 136638 8 mithraen 2013-01-07 19:30:25 +0400 Вариант с передачей списка email от самого cronbuild корректнее. ACL -- это кто имеет право обновлять пакеты. Операторы роботов это подмножество тех, кто указан в ACL. И если робот не смог собрать пакет -- эта информация крайне ценна для того, кто запросил автопересборку средствами cronbuild, но может восприниматься как спам всеми остальными. Но вариант с рассылкой по ACL все же гораздо лучше чем то, что есть сейчас -- когда в случае неудачной пересборки письма получает только cronbuild.