Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6079

Publisher hudson.tasks.Mailer aborted due to exception

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.352, Perforce plugin 1.0.24
    • Similar Issues:

      Description

      In a couple of recent builds, I received messages like this:

      ERROR: Publisher hudson.tasks.Mailer aborted due to exception

      java.lang.NullPointerException
      at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:41)
      at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:97)
      at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:465)
      at hudson.tasks.MailSender.buildCulpritList(MailSender.java:357)
      at hudson.tasks.MailSender.createEmptyMail(MailSender.java:338)
      at hudson.tasks.MailSender.createBackToNormalMail(MailSender.java:156)
      at hudson.tasks.MailSender.getMail(MailSender.java:147)
      at hudson.tasks.MailSender.execute(MailSender.java:81)
      at hudson.tasks.Mailer.perform(Mailer.java:101)
      at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
      at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582)
      at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)
      at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550)
      at hudson.model.Build$RunnerImpl.post2(Build.java:152)
      at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528)
      at hudson.model.Run.run(Run.java:1263)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:122)

      The projects it happened for were new (in Hudson) and had rather many changes in the depot (because they're old). Some of the users involved might not exist anymore (didn't check, but it's plausible given the age of the projects).
      Feel free to make the summary more accurately reflect what causes the problem (number of changes / users not existing).

        Attachments

          Activity

          Hide
          torbent torbent added a comment -

          (reformat the exception trace)

          Show
          torbent torbent added a comment - (reformat the exception trace)
          Hide
          torbent torbent added a comment -

          Perhaps this is related to JENKINS-5894 ?

          Show
          torbent torbent added a comment - Perhaps this is related to JENKINS-5894 ?
          Hide
          rpetti Rob Petti added a comment -

          The mail resolution needs to run perforce commands, and in order to do this, it needs access to the last node that the job was run on. In this case, the job was never run before, so it doesn't have a last node. I don't think there's any way to get the one that's currently being used, as silly as that sounds.

          In any case, this error should be handled properly.

          Show
          rpetti Rob Petti added a comment - The mail resolution needs to run perforce commands, and in order to do this, it needs access to the last node that the job was run on. In this case, the job was never run before, so it doesn't have a last node. I don't think there's any way to get the one that's currently being used, as silly as that sounds. In any case, this error should be handled properly.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
          http://jenkins-ci.org/commit/29298
          Log:
          [FIXED JENKINS-6079] added error handling for perforcemailresolver when the last node the job was run on doesn't exist (either because the build never ran, or the node was deleted)

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/29298 Log: [FIXED JENKINS-6079] added error handling for perforcemailresolver when the last node the job was run on doesn't exist (either because the build never ran, or the node was deleted)
          Hide
          torbent torbent added a comment -

          Sounds silly, indeed ...
          Anyway, it's not really a problem for me if the first build for a job cannot mail its result.

          Show
          torbent torbent added a comment - Sounds silly, indeed ... Anyway, it's not really a problem for me if the first build for a job cannot mail its result.
          Hide
          torbent torbent added a comment -

          Actually, I've had a build number 732 fail with this exception now.
          I cannot accurately determine what causes this, but I happened to discover a user (who had submitted in many, if not all, of the failing projects) whose email address was not set in Hudson. His address was set in Perforce, and there was no readily visible problem with his details in Perforce.
          Anyway, I'm running 1.0.26 now and will try deleting a couple of users (in Hudson) and see if they pop up correctly again. This user is a strong candidate for deletion

          Show
          torbent torbent added a comment - Actually, I've had a build number 732 fail with this exception now. I cannot accurately determine what causes this, but I happened to discover a user (who had submitted in many, if not all, of the failing projects) whose email address was not set in Hudson. His address was set in Perforce, and there was no readily visible problem with his details in Perforce. Anyway, I'm running 1.0.26 now and will try deleting a couple of users (in Hudson) and see if they pop up correctly again. This user is a strong candidate for deletion
          Hide
          rpetti Rob Petti added a comment -

          You can try enabling the logger hudson.plugins.perforce.PerforceMailResolver to see what is failing. If for some reason the node the job last ran on was deleted, or is offline, that would potentially cause this issue.

          Show
          rpetti Rob Petti added a comment - You can try enabling the logger hudson.plugins.perforce.PerforceMailResolver to see what is failing. If for some reason the node the job last ran on was deleted, or is offline, that would potentially cause this issue.
          Hide
          torbent torbent added a comment -

          I'll try enabling that logger. I renamed a slave (or two?) recently, but can't tell for sure whether this job would be effected ...

          Show
          torbent torbent added a comment - I'll try enabling that logger. I renamed a slave (or two?) recently, but can't tell for sure whether this job would be effected ...
          Hide
          rpetti Rob Petti added a comment -

          It might be time to refactor the way this thing works... I figure we should make it pull the usernames and emails of committers when grabbing changes and save it in the project for later retrieval by the mail resolver. That way we don't have to worry about trying to establish a new connection to perforce on a node that may or may not be online anymore.

          Show
          rpetti Rob Petti added a comment - It might be time to refactor the way this thing works... I figure we should make it pull the usernames and emails of committers when grabbing changes and save it in the project for later retrieval by the mail resolver. That way we don't have to worry about trying to establish a new connection to perforce on a node that may or may not be online anymore.
          Hide
          torbent torbent added a comment -

          I think you (or someone else) once claimed that mail resolving took place on the Master always?
          But I agree that it sounds like a good idea to automatically create committers as users, with resolved email addresses, as soon as we know of them.

          Show
          torbent torbent added a comment - I think you (or someone else) once claimed that mail resolving took place on the Master always? But I agree that it sounds like a good idea to automatically create committers as users, with resolved email addresses, as soon as we know of them.
          Hide
          rpetti Rob Petti added a comment -

          Yeah, it used to always take place on the master, but that caused problems for people with bizarre setups, such as the master not being able to see the configured perforce server on the network.

          Show
          rpetti Rob Petti added a comment - Yeah, it used to always take place on the master, but that caused problems for people with bizarre setups, such as the master not being able to see the configured perforce server on the network.
          Hide
          torbent torbent added a comment -

          I've had the logger you mentioned enabled for a day or two now, but nothing is logged. Does it only resolve users that do not already exist? Or am I doing something wrong?
          I set the logger class (I believe the term was) to "hudson.plugins.perforce.PerforceMailResolver" and have the loglevel set to "all".

          Show
          torbent torbent added a comment - I've had the logger you mentioned enabled for a day or two now, but nothing is logged. Does it only resolve users that do not already exist? Or am I doing something wrong? I set the logger class (I believe the term was) to "hudson.plugins.perforce.PerforceMailResolver" and have the loglevel set to "all".
          Hide
          rpetti Rob Petti added a comment -

          Yep, that's correct. If it's not showing anything, then that means the resolver isn't getting run by hudson. Likely because it's pulling the email from some other resolver, or directly from hudson's user list.

          Show
          rpetti Rob Petti added a comment - Yep, that's correct. If it's not showing anything, then that means the resolver isn't getting run by hudson. Likely because it's pulling the email from some other resolver, or directly from hudson's user list.
          Hide
          torbent torbent added a comment -

          Good. It's always nice to why software doesn't appear to behave the way one expects
          I never got around to deleting users, but will tomorrow. Perhaps I can reproduce something, despite having upgraded to 1.0.26 in the meantime.

          Show
          torbent torbent added a comment - Good. It's always nice to why software doesn't appear to behave the way one expects I never got around to deleting users, but will tomorrow. Perhaps I can reproduce something, despite having upgraded to 1.0.26 in the meantime.
          Hide
          torbent torbent added a comment -

          A couple of observations from logging (plugin version 1.0.26):

          • There's not always a correlation between the job being built and the job selected for query of email address. The log shows which job's SCM is being queried, and although it's usually the same as the build running, I've seen several cases where a different job's SCM was asked. There was such a case yesterday evening, when 5 different jobs where asked in quick succession about various users. This really becomes a problem when the jobs don't reside on the same Perforce server (yes ...)
          • Handling of unknown users. Apparently, Hudson wants to know the addresses of everyone who has submitted changes ever, not just in the current build (I think I'll submit a different issue on this), so in our case we risk resolving the addresses of people who are no longer employed here and are no longer in 'p4 users'. The plugin then makes a guess (user@clientname) which causes an exception elsewhere:

            javax.mail.internet.AddressException: Nested group in string ``usr@hudson::client::job_name'' at position 11

            at javax.mail.internet.InternetAddress.parse(InternetAddress.java:770)

            at javax.mail.internet.InternetAddress.parse(InternetAddress.java:555)

            at javax.mail.internet.InternetAddress.<init>(InternetAddress.java:91)

            at hudson.tasks.MailSender.buildCulpritList(MailSender.java:364)

            at hudson.tasks.MailSender.createEmptyMail(MailSender.java:341)

            at hudson.tasks.MailSender.createFailureMail(MailSender.java:207)

            at hudson.tasks.MailSender.getMail(MailSender.java:134)

            at hudson.tasks.MailSender.execute(MailSender.java:82)

            at hudson.tasks.Mailer.perform(Mailer.java:101)

            at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)

            at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582)

            at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)

            at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550)

            at hudson.model.Build$RunnerImpl.post2(Build.java:152)

            at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528)

            at hudson.model.Run.run(Run.java:1266)

            at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)

            at hudson.model.ResourceController.execute(ResourceController.java:88)

            at hudson.model.Executor.run(Executor.java:122)

            It's probably safer to return something that says "I don't know this user" or another error, and let the mailer try to form a name, e.g. from default domain etc.

          Show
          torbent torbent added a comment - A couple of observations from logging (plugin version 1.0.26): There's not always a correlation between the job being built and the job selected for query of email address. The log shows which job's SCM is being queried, and although it's usually the same as the build running, I've seen several cases where a different job's SCM was asked. There was such a case yesterday evening, when 5 different jobs where asked in quick succession about various users. This really becomes a problem when the jobs don't reside on the same Perforce server (yes ...) Handling of unknown users. Apparently, Hudson wants to know the addresses of everyone who has submitted changes ever , not just in the current build (I think I'll submit a different issue on this), so in our case we risk resolving the addresses of people who are no longer employed here and are no longer in 'p4 users'. The plugin then makes a guess (user@clientname) which causes an exception elsewhere: javax.mail.internet.AddressException: Nested group in string ``usr@hudson::client::job_name'' at position 11 at javax.mail.internet.InternetAddress.parse(InternetAddress.java:770) at javax.mail.internet.InternetAddress.parse(InternetAddress.java:555) at javax.mail.internet.InternetAddress.<init>(InternetAddress.java:91) at hudson.tasks.MailSender.buildCulpritList(MailSender.java:364) at hudson.tasks.MailSender.createEmptyMail(MailSender.java:341) at hudson.tasks.MailSender.createFailureMail(MailSender.java:207) at hudson.tasks.MailSender.getMail(MailSender.java:134) at hudson.tasks.MailSender.execute(MailSender.java:82) at hudson.tasks.Mailer.perform(Mailer.java:101) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550) at hudson.model.Build$RunnerImpl.post2(Build.java:152) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) at hudson.model.Run.run(Run.java:1266) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) It's probably safer to return something that says "I don't know this user" or another error, and let the mailer try to form a name, e.g. from default domain etc.
          Hide
          torbent torbent added a comment -

          I went more thoroughly through our logs and came across something which may be interesting, although it might not be the full problem

          Users that exist in Hudson but have blank email addresses seem to reliably provoke this:

          ERROR: Publisher hudson.tasks.Mailer aborted due to exception

          java.lang.NullPointerException

          at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:41)

          at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:97)

          at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:465)

          at hudson.tasks.MailSender.buildCulpritList(MailSender.java:360)

          at hudson.tasks.MailSender.createEmptyMail(MailSender.java:341)

          at hudson.tasks.MailSender.createBackToNormalMail(MailSender.java:157)

          at hudson.tasks.MailSender.getMail(MailSender.java:148)

          at hudson.tasks.MailSender.execute(MailSender.java:82)

          at hudson.tasks.Mailer.perform(Mailer.java:101)

          at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)

          at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582)

          at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)

          at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550)

          at hudson.model.Build$RunnerImpl.post2(Build.java:152)

          at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528)

          at hudson.model.Run.run(Run.java:1266)

          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)

          at hudson.model.ResourceController.execute(ResourceController.java:88)

          at hudson.model.Executor.run(Executor.java:122)

          It's hard to tell whether this happens because the email field is blank, or the field happens to remain blank because the plugin cannot resolve the user. This was found in PerforceMailResolver log at the same time:

          09-04-2010 10:53:04 hudson.plugins.perforce.PerforceMailResolver

          FINER: Checking JOB_B's SCM for SOMEONE's address.

          09-04-2010 10:53:04 hudson.plugins.perforce.PerforceMailResolver

          FINE: Email address for SOMEONE requested.

          (No, he's not called SOMEONE - I'm anonymising )
          The interesting bit is what's missing from the log, namely the succesful lookup and return of the address.
          What's also interesting is that we were not building JOB_B at the time, but (say) JOB_A.
          Actually, JOB_B is not set up for polling and hasn't been built at all since March 23rd. It does have a Perforce SCM, though, and it happens to use the same Perforce server as JOB_A. Not that it's vital, because SOMEONE is a user on both Perforce servers, and his email address is correctly registered on both.

          To twist it a bit further, JOB_A builds on our Master (Win XP) whereas JOB_B builds on a Linux slave.
          The Master relies on the Perforce user being logged in automatically (outside of Hudson) and JOB_B's slave requires the jobs to explicitly login via plugin configuration. Thus, the user/password fields of JOB_A are blank.

          That's the amount of detail I can think of right now. Do ask if you suspect something peculiar
          I haven't gone through all of our users to check for blank email addresses, but I know we have more than this one.

          Show
          torbent torbent added a comment - I went more thoroughly through our logs and came across something which may be interesting, although it might not be the full problem Users that exist in Hudson but have blank email addresses seem to reliably provoke this: ERROR: Publisher hudson.tasks.Mailer aborted due to exception java.lang.NullPointerException at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:41) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:97) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:465) at hudson.tasks.MailSender.buildCulpritList(MailSender.java:360) at hudson.tasks.MailSender.createEmptyMail(MailSender.java:341) at hudson.tasks.MailSender.createBackToNormalMail(MailSender.java:157) at hudson.tasks.MailSender.getMail(MailSender.java:148) at hudson.tasks.MailSender.execute(MailSender.java:82) at hudson.tasks.Mailer.perform(Mailer.java:101) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550) at hudson.model.Build$RunnerImpl.post2(Build.java:152) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) at hudson.model.Run.run(Run.java:1266) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) It's hard to tell whether this happens because the email field is blank, or the field happens to remain blank because the plugin cannot resolve the user. This was found in PerforceMailResolver log at the same time: 09-04-2010 10:53:04 hudson.plugins.perforce.PerforceMailResolver FINER: Checking JOB_B's SCM for SOMEONE's address. 09-04-2010 10:53:04 hudson.plugins.perforce.PerforceMailResolver FINE: Email address for SOMEONE requested. (No, he's not called SOMEONE - I'm anonymising ) The interesting bit is what's missing from the log, namely the succesful lookup and return of the address. What's also interesting is that we were not building JOB_B at the time, but (say) JOB_A. Actually, JOB_B is not set up for polling and hasn't been built at all since March 23rd. It does have a Perforce SCM, though, and it happens to use the same Perforce server as JOB_A. Not that it's vital, because SOMEONE is a user on both Perforce servers, and his email address is correctly registered on both. To twist it a bit further, JOB_A builds on our Master (Win XP) whereas JOB_B builds on a Linux slave. The Master relies on the Perforce user being logged in automatically (outside of Hudson) and JOB_B's slave requires the jobs to explicitly login via plugin configuration. Thus, the user/password fields of JOB_A are blank. That's the amount of detail I can think of right now. Do ask if you suspect something peculiar I haven't gone through all of our users to check for blank email addresses, but I know we have more than this one.
          Hide
          rpetti Rob Petti added a comment -

          Thanks for the info! It's always highly appreciated.

          The mail resolver base class is very generalized. It is designed by the core team to be run at any time, not just at the end of or during a build. As a result, there's no way to get the job that is currently running the Mail Publisher. This is why the plugin looks for the user's email in ALL perforce configured jobs that they have made changes to. As I've mentioned, I really need to figure out another way of doing this...

          As far as I know, the plugin doesn't attempt to 'guess' the email address by returning 'username'@'clientname'. That would just be weird. I'll need to look into this a bit more to figure out where the heck it is coming from, but I'm 90% sure it's not from the perforce mail resolver. The only place I can think of that uses that construct is in the changelogs, so if the mail publisher is looking there as well, it may just be a matter of populating the changelogs with the actual email address, and deleting the PerforceMailResolver entirely.

          I believe I fixed that nullpointer exception in 1.0.27. It had to do with trying to resolve using a job that last ran on a non-existent slave, or never ran at all.

          Show
          rpetti Rob Petti added a comment - Thanks for the info! It's always highly appreciated. The mail resolver base class is very generalized. It is designed by the core team to be run at any time, not just at the end of or during a build. As a result, there's no way to get the job that is currently running the Mail Publisher. This is why the plugin looks for the user's email in ALL perforce configured jobs that they have made changes to. As I've mentioned, I really need to figure out another way of doing this... As far as I know, the plugin doesn't attempt to 'guess' the email address by returning 'username'@'clientname'. That would just be weird. I'll need to look into this a bit more to figure out where the heck it is coming from, but I'm 90% sure it's not from the perforce mail resolver. The only place I can think of that uses that construct is in the changelogs, so if the mail publisher is looking there as well, it may just be a matter of populating the changelogs with the actual email address, and deleting the PerforceMailResolver entirely. I believe I fixed that nullpointer exception in 1.0.27. It had to do with trying to resolve using a job that last ran on a non-existent slave, or never ran at all.
          Hide
          torbent torbent added a comment -

          The NullPointerException may well be gone, but I cannot upgrade to 1.0.27 because of JENKINS-6173 (LineEnd defaults to "null"). I believe I have fewer Mailer errors than I would have LineEnd errors :-/

          The mail resolver sounds a bit strange ... but I do believe that the 'username'@'clientname' may come from either the plugin's population of the changelog, or ultimately from Perforce itself (that's the way the submitter is identified in the changelist).

          Show
          torbent torbent added a comment - The NullPointerException may well be gone, but I cannot upgrade to 1.0.27 because of JENKINS-6173 (LineEnd defaults to "null"). I believe I have fewer Mailer errors than I would have LineEnd errors :-/ The mail resolver sounds a bit strange ... but I do believe that the 'username'@'clientname' may come from either the plugin's population of the changelog, or ultimately from Perforce itself (that's the way the submitter is identified in the changelist).
          Hide
          rpetti Rob Petti added a comment -

          Ok, looks like 'username'@'clientname' is only used in the changelog view, so I have no idea where it came from in your case. Maybe one of your perforce servers has it defined as such?

          Show
          rpetti Rob Petti added a comment - Ok, looks like 'username'@'clientname' is only used in the changelog view, so I have no idea where it came from in your case. Maybe one of your perforce servers has it defined as such?
          Hide
          torbent torbent added a comment -

          I'm pretty sure the user in question didn't exist on either server. I also think that Perforce's default response to p4 user -o no_such_user is a ready-to-be-filled-in form with an email address of "no_such_user@whatever-client-is-being-used".
          Yup, just checked the docs: http://perforce.com/perforce/doc.092/manuals/cmdref/user.html
          "Email: The user's email address. By default, this is user@client."

          So Perforce will happily invent email addresses (and users) for us. Not too good. I'm not near a Perforce server until Monday, but perhaps the -s option has some use here? As in p4 -s user -o no_such_user - hopefully it will then respond with "error".

          Did a bit more reading in those docs. The users command seems to be our friend: http://perforce.com/perforce/doc.092/manuals/cmdref/users.html. The command p4 users who will give information about "who"; the information being a.o. username, real name, and email address. Presumably nothing will be returned if the user does not exist?

          Anyway, you could try playing around with it, perhaps? Or I can do it Monday.

          Show
          torbent torbent added a comment - I'm pretty sure the user in question didn't exist on either server. I also think that Perforce's default response to p4 user -o no_such_user is a ready-to-be-filled-in form with an email address of "no_such_user@whatever-client-is-being-used". Yup, just checked the docs: http://perforce.com/perforce/doc.092/manuals/cmdref/user.html " Email: The user's email address. By default, this is user@client. " So Perforce will happily invent email addresses (and users) for us. Not too good. I'm not near a Perforce server until Monday, but perhaps the -s option has some use here? As in p4 -s user -o no_such_user - hopefully it will then respond with "error". Did a bit more reading in those docs. The users command seems to be our friend: http://perforce.com/perforce/doc.092/manuals/cmdref/users.html . The command p4 users who will give information about "who"; the information being a.o. username, real name, and email address. Presumably nothing will be returned if the user does not exist? Anyway, you could try playing around with it, perhaps? Or I can do it Monday.
          Hide
          rpetti Rob Petti added a comment -

          Aha, that would explain it!

          I just tried p4 -s user -o USER and it doesn't error out, it just prepends every line with either 'error:' or 'info:', the actual information returned is still the same.

          I could try changing to p4 users, but that will require changing the tek42 libraries, so it might take me some time to get oriented with it. If a build is failing because of an invalid email address in the MailPublisher, then perhaps a bug should be filed against it as well.

          Show
          rpetti Rob Petti added a comment - Aha, that would explain it! I just tried p4 -s user -o USER and it doesn't error out, it just prepends every line with either 'error:' or 'info:', the actual information returned is still the same. I could try changing to p4 users, but that will require changing the tek42 libraries, so it might take me some time to get oriented with it. If a build is failing because of an invalid email address in the MailPublisher, then perhaps a bug should be filed against it as well.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Rob Petti
          Path:
          src/main/java/com/tek42/perforce/parse/Users.java
          src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
          http://jenkins-ci.org/commit/perforce-plugin/4ee1ee3baaeaaaee7bc0a1f5deaa345c614ffc9b
          Log:
          [FIXED JENKINS-6079] check to see if the user exists before attempting to get their information

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Rob Petti Path: src/main/java/com/tek42/perforce/parse/Users.java src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/perforce-plugin/4ee1ee3baaeaaaee7bc0a1f5deaa345c614ffc9b Log: [FIXED JENKINS-6079] check to see if the user exists before attempting to get their information

            People

            • Assignee:
              rpetti Rob Petti
              Reporter:
              torbent torbent
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: