Forgot to set component information

Can you verify that it does NOT hang when the e-mail is set to bobby@example.com? The code does not extend any special treatment for email addresses; it's just another field in the perforce response.

Also please ensure that all your perforce jobs are correctly configured, not just the one you are running.

I can verify it does not hang with other users who have matching usernames and email addresses. eg,

$ p4 user -o bbassett
...
Email: bbassett@example.com
...

Neither users have configuration records in HUDSON_HOME/users/${USERNAME}/config.xml.

All Perforce jobs appear to be configured correctly. They sync correctly from the depot when triggered; if there is a different definition to "correctly configured", I'd appreciate knowing

I forgot to mention this in the original report, but this configuration worked with version 1.0.15 of the Perforce plugin. Updating to 1.0.16 caused the issue to appear.

Our Perforce server is not named "perforce"; it is instead named "seaperforce.example.com", since the company I work for was acquired and the new company already had a "perforce.example.com". This issue regularly trips up our users, and might be a possible cause here.

As long as all the jobs can sync properly then that's fine. The MailAddressResolver classes cannot be tied to jobs, so it's forced to go through the perforce configurations one by one until it finds the user it's looking for (this includes disabled jobs as well, apparently). If a job isn't correctly configured, that could result in a hang (though really it should time out after a while).

In any case, I can't reproduce this behavior at all using 1.0.16 on hudson 1.318, or 1.0.18 on hudson 1.339.

It looks like the reason that it 'worked' in 1.0.15 is because the mail resolver was outright disabled. It looks like another user was running into the same issue, and just commented the entire thing out instead of trying to fix it.

One thing that comes to mind is that while perforce commands are run on the slave during a build, mail resolution actually takes place on the master. If the perforce server is reachable from the slaves, but not the master, then that would produce exactly the behavior you are seeing.

I'm having the exact same issue, it doesn't appear to timeout either, I let it go about 16 hours, and it was still hung. You also can't kill the job, I have to restart the Hudson master. A bit more info

Hudson 1.345 and 1.343
Perforce plugin 1.0.18
Perforce 2009.1(the api did change with 2009.1 so this may be something to look at)

It does work for users where the username and email match, but if any of the submitters don't match it hangs.

A bit more info. I'm running the hudson master on a windows box, as a service, using the localsystem account. Even though I create a p4ticket file(as a daemon user), it looks like the perforce plugin is having a hard time accessing it. I was playing with the tek42 api's and I couldn't access my server using my daemon p4 account. Once I switched to my local account, then I could switch back to the daemon account, and everything was fine. So

try {
                   Depot depot = new Depot();
                    depot.setUser("daemonuser");
       
                    depot.setPassword("daemonuserspassword");

                    depot.setPort("perforce:1666");
                    System.out.println("de: "+ depot.info());
                    com.tek42.perforce.model.User pu =depot.getUsers().getUser("ARealUser");

                    if (pu.getEmail() != null && !pu.getEmail().equals(""))
                        System.out.println("em" + pu.getEmail());

                } catch (Exception e) {
                    System.out.println("Could not get email address from Perforce: "+e.getMessage());
                }

This failed, the p4 info worked, but I couldn't get the email. Once I changed the depot.setusername to ARealUser, then I could get the email. Changing the depot.setusername back to daemonuser worked after that. Logging into p4v doesn't seem to fix anything.

So for valid testing it looks like you need to remove your ticket file.

bbassett: are you also running hudson on a windows server? Is it running as a service?

As a quick note, p4 info doesn't require a valid login (or even a username for that matter) in order to run, so it may not be the best test.

Tested with:
Hudson 1.345
Perforce Plugin 1.0.18
email-ext 2.5
p4 client 2009.1
p4d server 2009.2
Perforce security level 3

Removing the tickets file doesn't reproduce the problem on my end.

I've made some changes to the perforce email resolver that will make it a bit more robust. They'll be in 1.0.19, so please test again using that release.

No. We are running on a Linux master with both Linux and Windows slaves experiencing the issue.

Ok. In any case, give 1.0.19 a shot and let me know if anything changes.

Preliminary tests on 1.0.19 seems much better, it's not hanging, and finding the right email addresses, thank you so much! I only ran a few tests, so we'll see on monday once I start getting lots of users submitting.

Awesome! That's good to hear, because I was running out of ideas fast. I'll leave the bug open for a while in case something else comes up.

Spoke too soon I guess. I had to grab 1.0.20 to fix the SCM polling issue, and part of it is still fixed. I had a a few changes in a build, one by a daemon user, "build", with an email of releaseengineers@company.com, which did evaluate fine, but oddly enough real users don't resolve correctly. My usernames are <first initial><lastname> and their emails are <firstname>.<lastname>@company.com but the perforce plugin is resolving them to <first initial><lastname>@companyname.com so it's just using the username.

This only appears to be the case on linux slaves, windows slaves it behaves just fine, (both connected to a windows master) which makes me think it's a case sensitivity issue.

That's really bizarre that it doesn't work on linux slaves... The perforce mail resolver has no idea what job it's even resolving for, let alone what slave it's running on. Email resolution takes place globally. With that in mind, it's possible hudson can return the email address as it's defined in another SCM entirely. As long as the username has made commits to the SCM as defined by any job, it should try and grab the email from it. Then it will just return whichever one it finds first.

The only thing I can think of is that hudson is just grabbing the last resolved email from the previous builds for those jobs that are running on the linux slaves, which may have been the default "username@defaultdomain" construct. During testing, I've had to delete all previous builds for the test job (HUDSON_HOME/jobs/JOBNAME/builds/*) as well as any users that may have been accidentally defined (HUDSON_HOME/users). Otherwise, the perforce plugin doesn't even get a shot at getting the email address.

I created a new job on a new linux slave, and it doesn't resolve correctly. Use the same job, change it to a windows slave, it resolves correctly. Change it back to linux slave, and it fails to resolve again.

Then I created a new job, new windows slave, new linux slave, ran it on windows first, email resolves correctly, change the job to linux, and it fails.

Do you have any log output for those failures?

Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/tasks/MailAddressResolver.java
http://jenkins-ci.org/commit/27623
Log:
JENKINS-5403 adding more logging in MailAddressResolver to help us figure out what's going on.

I guess I should have looked at the log earlier, I was only looking at the error log, but this was in the hudson.out.log

[hudson] $ /usr/local/bin/p4 user -o perforce
Could not get email address from Perforce: Could not run perforce command.

Not sure why it doesn't work, that is the path to p4, but at least I have something to go on now.

There's supposed to be a stack trace accompanying that message. I'll look into why it's not printing.

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
http://jenkins-ci.org/commit/27659
Log:
JENKINS-5403 adding additional logging (printStackTrace) for perforcemailresolver

I've attached a svn snapshot build of the previous commit, so we should be able to see why it can't run the perforce command.

I can build it locally as well, which is what I did, ignore the ": not set", that was me adding some debugging, I'm new to plugin development.

Could not get email address from Perforce: Could not run perforce command.
com.tek42.perforce.PerforceException: Could not run perforce command.: not set
	at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:85)
	at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:284)
	at com.tek42.perforce.parse.Users.getUser(Users.java:52)
	at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:53)
	at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:81)
	at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:476)
	at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:293)
	at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:227)
	at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:219)
	at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:180)
	at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
	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.cleanUp(Build.java:158)
	at hudson.model.Run.run(Run.java:1240)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:122)
Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson"): CreateProcess error=3, The system cannot find the path specified
	at java.lang.ProcessBuilder.start(Unknown Source)
	at hudson.Proc$LocalProc.<init>(Proc.java:149)
	at hudson.Proc$LocalProc.<init>(Proc.java:121)
	at hudson.Launcher$LocalLauncher.launch(Launcher.java:633)
	at hudson.Launcher$ProcStarter.start(Launcher.java:268)
	at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:75)
	... 18 more
Caused by: java.io.IOException: CreateProcess error=3, The system cannot find the path specified
	at java.lang.ProcessImpl.create(Native Method)
	at java.lang.ProcessImpl.<init>(Unknown Source)
	at java.lang.ProcessImpl.start(Unknown Source)

I should note that the sync works, so the path is correct, it's only on the email resolve. At least I think that makes sense.

Can you rebuild from latest and try again, please?

Same error, same stack trace

Ok, I was able to reproduce the problem by specifying an invalid root directory for the linux node. I used backslashes instead of slashes, and while that allows the sync to work properly (not sure how yet), the email resolution still fails.

This line

Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson"): CreateProcess error=3, The system cannot find the path specified

Suggests that you have "\usr\local\hudson" set as the node's root instead of /usr/local/hudson. Is this the case?

Nope, I double checked, /usr/local/hudson is the path in hudson(I even checked the config.xml to make sure it wasn't a display thing)

Code changed in hudson
User: : rpetti
Path:
trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
http://jenkins-ci.org/commit/27661
Log:
JENKINS-5403 change the ad-hoc launcher in PerforceMailResolver to one created by the node instead of the master

One more time? After this I'll be completely out of ideas.

That did it, works great now, thank you so much!

Awesome!

Fixed in subversion, will be in the 1.0.21 release.