Bug 27637

Summary: ssh git.alt task run --email <mail addr> option
Product: Infrastructure Reporter: viy <viy>
Component: girarAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: Andrey Cherepanov <cas>
Severity: enhancement    
Priority: P3 CC: glebfm, ldv, mithraen
Version: unspecified   
Hardware: all   
OS: Linux   

Description viy 2012-08-13 15:22:01 MSK
Добавьте, пожалуйста, опцию --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
Comment 1 viy 2012-08-24 12:58:32 MSK
важно для cornbuild/corncopy/cronport
Comment 2 viy 2012-10-04 12:48:17 MSK
На всякий случай еще раз напоминаю про опцию --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
Comment 3 Denis Smirnov 2013-01-02 06:53:06 MSK
Вот сегодня опять была проблема -- один из моих моих пакетов, который поддерживается cronbuild почему-то не собрался (task #87283).

Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил, а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты).
Comment 4 Dmitry V. Levin 2013-01-06 18:09:50 MSK
(In reply to comment #3)
> Вот сегодня опять была проблема -- один из моих моих пакетов, который
> поддерживается cronbuild почему-то не собрался (task #87283).
> 
> Сообщение об ошибке я, как мантейнер (который будет пакет фиксить) не получил,
> а получил это только cronbuild@ (который робот, и не умеет фиксить пакеты).

Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы иметь возможность выставлять заданию свойство отправлять уведомления в соответствии с ACL собираемых пакетов не только при успешной сборке, но и при неудаче на более ранних стадиях обработки задания.
Comment 5 viy 2013-01-06 21:35:53 MSK
(В ответ на комментарий №4)
> Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы
> иметь возможность выставлять заданию свойство отправлять уведомления в
> соответствии с ACL собираемых пакетов не только при успешной сборке, но и при
> неудаче на более ранних стадиях обработки задания.

А почему бы не сделать сразу два варианта? и грубый --<явно указать кому>
и более специальный - "отправлять уведомления в соответствии с ACL ..."
Ведь только второго варианта недостаточно - с ним при желании не отключишь отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075 сборок, это 2075 spam messages.
Один универсальный инструмент в природе редко встречается.
Кому-то молоток нужен, а кому-то топор. Скрещивать их в микроскоп не нужно.

С наступающим Рождеством!
Comment 6 Dmitry V. Levin 2013-01-06 21:56:02 MSK
(In reply to comment #5)
> (В ответ на комментарий №4)
> > Мне кажется, что этот конкретный вопрос удобнее решать иначе: мне хотелось бы
> > иметь возможность выставлять заданию свойство отправлять уведомления в
> > соответствии с ACL собираемых пакетов не только при успешной сборке, но и при
> > неудаче на более ранних стадиях обработки задания.
> 
> А почему бы не сделать сразу два варианта? и грубый --<явно указать кому>

Дело в том, что cronbuild не может точно знать, кому.  Он только знает, кто ему дал задание, и все.  Есть ли случаи, когда достаточно отправлять уведомления только своему инструктору вместо всех членов ACL?

> и более специальный - "отправлять уведомления в соответствии с ACL ..."
> Ведь только второго варианта недостаточно - с ним при желании не отключишь
> отсылку писем на cronbuild. За 2012 год cronbuild отправил в incoming 2075
> сборок, это 2075 spam messages.

Флажок "не отправлять уведомления мне" тоже может быть полезен.
Comment 7 viy 2013-01-06 22:24:02 MSK
(В ответ на комментарий №6)
> (In reply to comment #5)
> Дело в том, что cronbuild не может точно знать, кому.  Он только знает, кто ему
> дал задание, и все.  Есть ли случаи, когда достаточно отправлять уведомления
> только своему инструктору вместо всех членов ACL?

Вроде бы пока все случаи только такие. Если возникнет прецедент, то
можно будет сдеать объезд в самом cronbuild, ему можно будет добавить
в cronbuild переменную, где хранить список аргументов для --<обсуждаемой опции>

и тот кто заказал пакет, может настроить в пакете явную рассылку.
при условии, что в --<обсуждаемой опции> будет поддержка нескольких указаний опции или нескольких аргументов.
Comment 8 Denis Smirnov 2013-01-07 19:30:25 MSK
Вариант с передачей списка email от самого cronbuild корректнее.

ACL -- это кто имеет право обновлять пакеты. Операторы роботов это подмножество тех, кто указан в ACL. И если робот не смог собрать пакет -- эта информация крайне ценна для того, кто запросил автопересборку средствами cronbuild, но может восприниматься как спам всеми остальными.

Но вариант с рассылкой по ACL все же гораздо лучше чем то, что есть сейчас -- когда в случае неудачной пересборки письма получает только cronbuild.