-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Jenkins 2.278
email-ext 2.81
Our pipeline tries to send an email as a post-action, but due to some failure it breaks the build.
Stack trace reveals the email-ext plugin somehow tries to process the "null" user (wrong data provided by some other component?) and it fails to do so.
[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Declarative: Post Actions)[Pipeline] emailextrecipientsError when executing always post condition: org.springframework.security.authentication.DisabledException: The user "null" is administratively disabled. at hudson.security.UserAttributesHelper.checkIfUserEnabled(UserAttributesHelper.java:92) at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:1314) at hudson.security.LDAPSecurityRealm$DelegateLDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:1227) at jenkins.security.ImpersonatingUserDetailsService2.loadUserByUsername(ImpersonatingUserDetailsService2.java:29) at hudson.model.User.getUserDetailsForImpersonation2(User.java:399) at hudson.model.User.impersonate2(User.java:367) at hudson.model.User.impersonate(User.java:377) Caused: org.acegisecurity.DisabledException: org.springframework.security.authentication.DisabledException: The user "null" is administratively disabled.; nested exception is org.springframework.security.authentication.DisabledException: The user "null" is administratively disabled. at org.acegisecurity.DisabledException.fromSpring(DisabledException.java:51) at org.acegisecurity.AuthenticationException.fromSpring(AuthenticationException.java:88) at hudson.model.User.impersonate(User.java:379) at hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.addUsers(RecipientProviderUtilities.java:171) at hudson.plugins.emailext.plugins.recipients.RecipientProviderUtilities.addUsers(RecipientProviderUtilities.java:153) at hudson.plugins.emailext.plugins.recipients.CulpritsRecipientProvider.addRecipients(CulpritsRecipientProvider.java:60) at hudson.plugins.emailext.EmailExtRecipientStep$Executor.run(EmailExtRecipientStep.java:69) at hudson.plugins.emailext.EmailExtRecipientStep$Executor.run(EmailExtRecipientStep.java:42) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)[Pipeline] script[Pipeline] {
The relevant part of the pipeline:
emailext (
attachLog: true,
body: '${DEFAULT_CONTENT}',
mimeType: 'text/html',
replyTo: '${DEFAULT_REPLYTO}',
subject: '${DEFAULT_SUBJECT}',
to: emailextrecipients([
[$class: 'CulpritsRecipientProvider'],
[$class: 'RequesterRecipientProvider'],
[$class: 'DevelopersRecipientProvider']
]),
)
- relates to
-
JENKINS-55813 Improve AD/LDAP attribute analysis for locked accounts
-
- Resolved
-
[JENKINS-64850] Build fails due to emailext trying to send mail to "null" user
Basil Crow
added a comment - Hi pistahh, thanks for reporting this but I doubt the issue lies in Email Extension. In both this bug and JENKINS-64629, the email plugins are just calling the Jenkins core API jenkins.scm.RunWithSCM#getCulprits to get a set of User objects, then calling the Jenkins core API hudson.model.User#impersonate() to impersonate each user. That API in turn is delegating to the LDAP plugin in your case.
If this is a change in behavior, it might be caused by fallout from JEP-227. Either way, I doubt I can be of much assistance here. I added the ldap-plugin component and the JEP-227 label to this bug; hopefully that will get the right set of eyes on this.
Basil Crow
added a comment - Hi pistahh , thanks for reporting this but I doubt the issue lies in Email Extension. In both this bug and JENKINS-64629 , the email plugins are just calling the Jenkins core API jenkins.scm.RunWithSCM#getCulprits to get a set of User objects, then calling the Jenkins core API hudson.model.User#impersonate() to impersonate each user. That API in turn is delegating to the LDAP plugin in your case.
If this is a change in behavior, it might be caused by fallout from JEP-227 . Either way, I doubt I can be of much assistance here. I added the ldap-plugin component and the JEP-227 label to this bug; hopefully that will get the right set of eyes on this. Basil Crow
added a comment - I looked a little deeper into the LDAP plugin issues and I think this is more likely related to JENKINS-55813 than JEP-227, so I removed the JEP-227 label.
Basil Crow
added a comment - I looked a little deeper into the LDAP plugin issues and I think this is more likely related to JENKINS-55813 than JEP-227, so I removed the JEP-227 label. Basil Crow
added a comment - Duplicates JENKINS-64629 . Being addressed in https://github.com/jenkinsci/email-ext-plugin/pull/277
Similar issue resolving the "null" user but by another plugin in JENKINS-64629 .