Дженкинс отказывается отправлять сообщения об ошибках некоторым пользователям. В журнале я нашел эти сообщения:
....
Build step 'Maven Goals aufrufen' marked build as failure
Not sending mail to unregistered user [email protected]
Sending e-mails to: [email protected]
Finished: FAILURE
Пользователь (user1) указан в списке администраторов. У него также зарегистрировано электронное письмо ([email protected]).
Итак, почему этот пользователь вызвал незарегистрированного пользователя?
При поиске этого предупреждения я обнаруживаю несколько открытых проблем JIRA, таких как https://issues.jenkins-ci.org/browse/JENKINS-43178 Но это мне не помогает.
Является ли это неправильной конфигурацией или ошибкой jenkins?
У незарегистрированного пользователя не было пароля jenkins. После ввода пароля в поле пароля пользователя jenkins почтовые отправления отправляются этому пользователю.
Чтобы ввести пароль
Проблема была (для меня):
SECURITY-372 (advisory) Emails were sent to addresses not associated with
actual users of Jenkins.
Я использую Jenkins с триггером Gerrit для вновь созданных наборов патчей или опубликованных черновиков. С помощью этого "исправления" безопасности Дженкинс попытается "угадать" имя пользователя по имени перед адресом электронной почты. Например, в разделе "Имя-фамилия" часть "Имя-фамилия" будет именем пользователя, которое jenkins пытается найти в пользовательской базе данных Jenkins, но эта комбинация не совпадает с идентификатором, который используется в нашей LDAP, и, таким образом, jenkins не будет отправлять электронные письма. нет... если:
https://wiki.jenkins.io/display/JENKINS/Email-ext+plugin#Email-extplugin-2.57.2(April10,2017)
If the security fix is undesirable in a particular instance, it can be disabled with either or both of the following two system properties:
-Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true: send mail to build culprits even if they do not seem to be associated with a valid Jenkins login.
-Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true: send mail to build culprits associated with a valid Jenkins login even if they would not otherwise have read access to the job.
Эти JAVA_ARGS могут быть добавлены в /etc/default/jenkins или /etc/sysconfig/jenkins, в зависимости от вашего дистрибутива.
Там Allow sending to unregistered users настройки в меню Configure System по крайней мере, в Jenkins 2.150.1.
Чтобы прояснить ответ Маттиаса: Даже если учетная запись пользователя создается во время сборки (поскольку SCM предоставляет информацию об коммиттерах), он по-прежнему остается незарегистрированным пользователем Дженкинса. Таким образом, никакие электронные письма не будут отправлены этому пользователю.
Если вы перейдете к соответствующей учетной записи пользователя в <your-jenkins-URL>/asynchPeople/, вы можете настроить эту учетную запись и ввести для нее пароль. Теоретически, пользователь может войти в Jenkins, используя этот пароль, сейчас. И как только учетная запись пользователя Jenkins имеет связанный пароль, она больше не считается "незарегистрированной". И получат уведомления по электронной почте. Вуаля.
Из ОП не ясно, используют ли они LDAP, но вот некоторая информация, которая решила это для меня, и которую я нигде не нашел, включая Jenkins JIRA.
Следующее предложение:
-Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS = истина
так же как:
Разрешить отправку незарегистрированным пользователям
а также:
Создать коммиттер как пользователь Jenkins
не работал для меня. Однако первый ответ поставил меня на путь решения проблемы. Оказывается, что при использовании LDAP Jenkins фактически сопоставляется с именем пользователя коммиттера git. Так что, если сообщение git commit:
Committer: John Doe <[email protected]> 2019-05-27 19:12:00
Дженкинс возьмет "Джон Доу", преобразует его в "john.doe" и попытается сопоставить с LDAP. Теперь, если ваше имя пользователя LDAP - "john.doe", вы в порядке, но в моем случае стандарт компании - "doejohn", что приведет к страшному сообщению:
Not sending mail to unregistered user [email protected]
Это сообщение вводит в заблуждение, так как показывает правильный адрес электронной почты вместо упоминания выдуманного (несуществующего) имени пользователя. Решением для меня было настроить имя пользователя git на "doejohn":
$ git config --global user.name "doejohn"