Добавьте, пожалуйста, опцию --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
важно для cornbuild/corncopy/cronport
На всякий случай еще раз напоминаю про опцию --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
Вот сегодня опять была проблема -- один из моих моих пакетов, который поддерживается cronbuild почему-то не собрался (task #87283). Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил, а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты).
(In reply to comment #3) > Вот сегодня опять была проблема -- один из моих моих пакетов, который > поддерживается cronbuild почему-то не собрался (task #87283). > > Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил, > а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты). Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы иметь возможность выставлять заданию свойство отправлять уведомления в соответствии с ACL собираемых пакетов не только при успешной сборке, но и при неудаче на более ранних стадиях обработки задания.
(В ответ на комментарий №4) > Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы > иметь возможность выставлять заданию свойство отправлять уведомления в > соответствии с ACL собираемых пакетов не только при успешной сборке, но и при > неудаче на более ранних стадиях обработки задания. А почему бы не сделать сразу два варианта? и грубый --<явно указать кому> и более специальный - "отправлять уведомления в соответствии с ACL ..." Ведь только второго варианта недостаточно - с ним при желании не отключишь отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075 сборок, это 2075 spam messages. Один универсальный инструмент в природе редко встречается. Кому-то молоток нужен, а кому-то топор. Скрещивать их в микроскоп не нужно. С наступающим Рождеством!
(In reply to comment #5) > (В ответ на комментарий №4) > > Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы > > иметь возможность выставлять заданию свойство отправлять уведомления в > > соответствии с ACL собираемых пакетов не только при успешной сборке, но и при > > неудаче на более ранних стадиях обработки задания. > > А почему бы не сделать сразу два варианта? и грубый --<явно указать кому> Дело в том, что cronbuild не может точно знать, кому. Он только знает, кто ему дал задание, и все. Есть ли случаи, когда достаточно отправлять уведомления только своему инструктору вместо всех членов ACL? > и более специальный - "отправлять уведомления в соответствии с ACL ..." > Ведь только второго варианта недостаточно - с ним при желании не отключишь > отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075 > сборок, это 2075 spam messages. Флажок "не отправлять уведомления мне" тоже может быть полезен.
(В ответ на комментарий №6) > (In reply to comment #5) > Дело в том, что cronbuild не может точно знать, кому. Он только знает, кто ему > дал задание, и все. Есть ли случаи, когда достаточно отправлять уведомления > только своему инструктору вместо всех членов ACL? Вроде бы пока все случаи только такие. Если возникнет прецедент, то можно будет сдеать объезд в самом cronbuild, ему можно будет добавить в cronbuild переменную, где хранить список аргументов для --<обсуждаемой опции> и тот кто заказал пакет, может настроить в пакете явную рассылку. при условии, что в --<обсуждаемой опции> будет поддержка нескольких указаний опции или нескольких аргументов.
Вариант с передачей списка email от самого cronbuild корректнее. ACL -- это кто имеет право обновлять пакеты. Операторы роботов это подмножество тех, кто указан в ACL. И если робот не смог собрать пакет -- эта информация крайне ценна для того, кто запросил автопересборку средствами cronbuild, но может восприниматься как спам всеми остальными. Но вариант с рассылкой по ACL все же гораздо лучше чем то, что есть сейчас -- когда в случае неудачной пересборки письма получает только cronbuild.
