При добавлении триггера, можно выбратьКаковы получатели уведомлений электронной почты с расширением электронной почты Jenkins?
и еще несколько вариантов.
При использовании Git в SCM, как те, получатель списки точно определяется?
Существует хорошее объяснение на Email-ext plugin странице:
Отправить письмо для тех, кто проверил в коде для последней сборки. Плагин будет генерировать адрес электронной почты на основе идентификатора коммиттера и добавленного «суффикса по умолчанию» по умолчанию на странице глобальной конфигурации Jenkins. Например, если изменение было совершено кем-то с идентификатором «first.last», а суффикс по умолчанию - «@ where.com», то электронное письмо будет отправлено на адрес «[email protected]»
отправляет по электронной почте список пользователей, которые совершили изменения с момента последней ненарушенной сборки до сих пор. Этот список, по крайней мере, всегда включает людей, внесших изменения в эту сборку, но если предыдущая сборка была неудачной, она также включает список преступников.
Я предполагаю, что алгоритм определения электронной почты culprint такой же, как для разработчика.
Не совсем понятно для меня, что означает «любой, кто проверил код» в нетривиальном контексте Git. Особенно: обычно содержимое «центрального» репозитория Git не изменяется за счет фиксации, а путем нажатия и иногда слияния. В чем разница между разработчиками и виновниками? Объяснение «виновников» ограничивает соответствующий временной интервал (который опять нетривиальным в контексте Git) к тому, что начинается с последней сломанной сборки. Кажется, что нет никаких ограничений для «разработчиков». Но это, вероятно, не означает, что электронные письма распространяются на всех разработчиков, которые когда-либо совершали. – Gustave
Недавно у меня была электронная почта для более чем 40 разработчиков (как преступников). Я не понял, что там происходит, но это было окончательно не-go, а не поведение, которое я ожидал, прочитав эти два «хороших объяснения». В тексте прописано «список пользователей, совершивших изменение». Как правило, фиксация в Git связана с одним пользователем, а не с списком пользователей. – Gustave
Судьи уже внедрены в Jenkins Core. – Gustave