Which version of Jenkins and which version of the Perforce Plugin are you using?

Why do you say it's using the CmdLineExecutor class? On the master, it uses the Launcher class, which in turn uses the LocalLauncher class. On the slave it's using a custom class which in turn uses a LocalLauncher to perform the actual execution. They both end up using the exact same code to perform the execution.

If your master is 2008 as you say, then this could just be a problem with 2008R2 and have nothing to do with the fact that it's running as a slave.

All that being said, I'm unable to reproduce this problem. There aren't any issues when running the perforce plugin on a WS2008R2 slave machine. Make sure your perforce connection information is correct in the plugin configuration. The error you are getting suggests a problem with the configuration, and not anything to do with the way windows handles command line arguments. It's possible that the problem only exists in a particular version of Jenkins and/or the plugin, so I'll need to know what versions you are running in order to be sure.

Cannot reproduce, and insufficient information provided.

I'm actually having the exact same issue; perhaps I can provide more info. I'm running Jenkins 1.411 on an AIX (5.3) box, and the slave is on Windows 2008(R2). The perforce plugin is 1.2.5. On the slave, I have run p4 commands that contain the same configuration as I entered into Jenkins, and they work fine. I have tried using both the perforce server name and the IP in the P4PORT field in Jenkins. I still get the "Connect to server failed; check $P4PORTcom.tek42.perforce.PerforceException" error. This same configuration worked when the slave was a WinXP PC.

Can you also provide me with:
The version of your perforce client on the slave.
The version of your perforce server.
The version of Java installed on the slave.
The version of Java installed on the master.

The version of your perforce client on the slave: Perforce Visual Client/NTX86/2010.2/317255
The version of your perforce server: P4D/LINUX26X86_64/2009.2/256645 (2010/07/26)
The version of Java installed on the slave: 1.6
The version of Java installed on the master: 1.5

Perforce Visual Client/NTX86/2010.2/317255 Is not a command line client... If this is what you are pointing your perforce configuration to, then that's why it's not working. If this is the case, you need to download and install the command line client (p4.exe) and use that instead. Also be sure to download 2009.2 so it matches your server version.

I retested using Jenkins 1.411 on a modern linux master and my results were the same as before; everything is working fine.

I'm attempting to run Jenkins 1.411 on an AIX machine now, and I'm not having much luck getting the slave connected at all. I'm using IBM's JVM v1.5, and I'm getting plenty of errors when trying to connect the slave. Which specific version of Java are you running on your master? "1.5" isn't enough information, I need the full output of 'java -version'.

Jenkins master is running inside Tomcat. Here's the java info:

$ /usr/java5/bin/java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pap32devifx-20061013 (ifix 110617: SR3 + 109092))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223ifx-20061013 (JIT enabled)
J9VM - 20061012_08722_bHdSMR
JIT - 20060908_1811ifx1_r8
GC - 20060906_AA)
JCL - 20061002

I am running the p4 command line client on the slave; I believe it's the version that was included in the p4V installation. I will make sure I sync the versions between that and the p4 server.

That looks like pretty much the same JVM I have (If slightly older). I managed to get Jenkins running properly on my test system by clearing out JENKINS_HOME, and I'm getting the same results as before. Perforce operations on the Windows 2008 R2 slave are working normally.

One thing that comes to mind is that I was unable to get the slave connected by just clicking the jnlp launch icon on the Jenkins page. I had to run it as if the slave was headless by running the following in a command window:

java -jar slave.jar -jnlpUrl http://jenkins/computer/ws2008r2/slave-agent.jnlp

You may wish to try the same to see if it affects your results. It could be a bizarre Windows permissions issue...

Rob, thank you for the time you've spent on this up to this point. Unfortunately, I'm not any further along. I can connect to the slave in several ways. But no matter how I configure the p4 plugin within my build job on the master (the P4PORT, Username, and Password), it seems to make no difference. I can put in the correct info, garbage, or nothing, and I get the same error about a failed connection. I wish there were a way to see that the connection information was being properly communicated to the slave.

Maybe this detail will help: The slave machine is in a different corporate domain within our network, and I have to sign on with a different ID. This ID does not have access to our p4 server (and cannot get access – corporate policy). So I have configured the job on the master to use my "master" id to connect to p4. The Jenkins console output tells me that is trying to run the following command:

p4 workspace -o <name-of-my-workspace>

I can run this command on the slave machine only if I login to p4 first (with my "master" ID):

p4 -u <my-master-id> login -p

and then I can run:

p4 -u <my-master-id> workspace -o <name-of-my-workspace>

My assumption is that Jenkins passes the connection info to the slave, so it won't try and connect to p4 using my "slave" id. But it's not working. I wonder if I can somehow reference a script on the slave that would explicitly log me into p4 (with my "master" id); maybe a pre-build step? I'm reaching here...

That's correct, the connection info is passed to the slave through environment variables whenever p4 is called. The original poster suggested that the problem was with the way Windows 2008 R2 parses command line arguments, but since none are being used to pass the connection information I don't see how that could be the problem.

To check to see if the variables are being set correctly, you can try creating a batch file like the following:

@echo off
set > C:\test.txt

And set it as your p4.exe in the plugin configuration. Next time you run the build, it'll populate test.txt with the environment that Jenkins sets up for perforce when trying to do perforce operations. See if P4CLIENT, P4USER and P4PORT are all being set correctly.

Out of curiosity, are you running the slave as an administrator on the Windows 2008 R2 machine, or an unprivileged user?

1. I am not an administrator on the slave machine. However, I can launch a powershell session as administrator, so I did that, and started the slave from there. No luck; still got the same p4 connection error.
2. Great idea on the script. I did that and was able to confirm that the correct values for P4PORT, P4USER, and P4PASSWD are being set.
3. Here's the weirdness: Every time I try to run my job, I get:

   Started by user anonymous
   ln -s 2011-06-21_17-36-03 /sdcoe/jenkins/jobs/AO_SISO_AT-smoketest-CIT1/builds/48 failed: -1 
   Building remotely on 10.40.163.105
   Using remote perforce client: jenkins-AO_SISO_AT-smoketest-CIT1-1858902131
   [AO_SISO_AT-smoketest-CIT1] $ p4 workspace -o jenkins-AO_SISO_AT-smoketest-CIT1-1858902131
   Caught exception communicating with perforce. Connect to server failed; check $P4PORTcom.tek42.perforce.PerforceException: Connect to server failed; check $P4PORT
   

   BUT, I made a mistake at some point, in that I used the little script you suggested, but I had it writing to a directory to which I did not have write privileges. So in other words, in the Jenkins job config, the p4 executable was set to this little script, which I called p4-catch.bat, but the script couldn't write its output file. Not realizing this at first, I ran my job. Check out the output (this is reproducable):

   Started by user anonymous
   ln -s 2011-06-21_17-41-18 /sdcoe/jenkins/jobs/AO_SISO_AT-smoketest-CIT1/builds/49 failed: -1 
   Building remotely on 10.40.163.105
   Using remote perforce client: jenkins-AO_SISO_AT-smoketest-CIT1-1858902131
   [AO_SISO_AT-smoketest-CIT1] $ c:\\Users\\nbem3al\\p4-catch.bat workspace -o jenkins-AO_SISO_AT-smoketest-CIT1-1858902131
   Changing P4 Client Root to: c:\jenkins-slave\workspace\AO_SISO_AT-smoketest-CIT1
   Changing P4 Client View from:
   
   Changing P4 Client View to: 
     //sdcoe/apps/WebTests/... //jenkins-AO_SISO_AT-smoketest-CIT1-1858902131/sdcoe/apps/WebTests/...
   Saving new client jenkins-AO_SISO_AT-smoketest-CIT1-1858902131
   [AO_SISO_AT-smoketest-CIT1] $ c:\\Users\\nbem3al\\p4-catch.bat -s client -i
   Last build changeset: 867218
   [AO_SISO_AT-smoketest-CIT1] $ c:\\Users\\nbem3al\\p4-catch.bat counter change
   Caught exception communicating with perforce. Could not get value of counter.
   Response from perforce was:
   Access is denied.
   com.tek42.perforce.PerforceException: Could not get value of counter.
   

   With no p4 executable set in the job config, but rather a DOS script that has an error, I actually get further into the p4 steps than I have before. I can't figure that out.

I can probably shed some light on this for you.

Basically when it runs

c:\\Users\\nbem3al\\p4-catch.bat workspace -o jenkins-AO_SISO_AT-smoketest-CIT1-1858902131

It doesn't return any error message that the plugin knows about, so it proceeds as if nothing is wrong. This should throw some kind of parsing error early on, but I guess it's not robust enough. From there it 'changes' the client view from nothing (since nothing intelligible was returned) to the new view. The batch script just eats it, and the plugin continues on happily.

The Last build changeset is from the previous successful build (I guess you had it on a different slave before) so it's not actually getting it from perforce.

It's not until it tries to parse the output of the counter command that it fails. There's a check in there to make sure the result is in fact a number. In this case, the batch script was returning "Access is denied." because of the illegal file write.

So you aren't actually getting any further, the plugin just doesn't know to look for that kind of error.

So back to the issue at hand.

If the environment variables are being set correctly, but the connection is still failing that can really only mean one thing. Windows is likely blocking connections from child processes. That would explain why it works by hand, but not through the slave agent.

This really wouldn't surprise me, because I think you need to add it as an exception to the windows firewall for outgoing connections. It might be working on my test machine because I'm using the Administrator account with the firewall disabled. Tomorrow I'll try to see if I can replicate the results by re-enabling the firewall and running the slave as a general user.

Thanks for that explanation. "Who are you that are so wise in the ways of science?"

BTW, I tried running Jenkins as a master instance on my slave machine, and got the same error. So I can request a firewall rule change, but I haven't been able to find any reference to firewall rules that pertain to child processes. Do you know how I would characterize this Jenkins slave process when configuring a firewall change?

It would just be the p4 executable. You would basically add an outbound rule allowing all connections from the perforce client binary in "Windows Firewall with Advanced Security". Alternatively, you could add a new outbound rule allowing all connections on remote port 1666 (or whatever port number you are using for perforce).

In any case, I'm not able to replicate your results when using an unprivileged user with the windows firewall enabled with the default settings. Something else must be going on...

Well, I think we probably are using something other than the default settings; I don't have the privileges to view them.

There's one more thing I'm unclear on: from the firewall's perspective, what's the difference between me running the "p4 workspace -o <name-of-my-workspace>" command from the powershell versus the same command being run by the Jenkins' slave agent? I will request a firewall rule change, but I want to make sure I'm requesting the right thing.

I'm unclear on that as well, and I admit I'm starting to grasp at straws here. Windows permissions are pretty alien to me, but I think when you run it explicitly it somehow gets more privileges than when you run it as a child of another process. I could be wrong of course...

Here's some more info: On the slave machine, I created a batch file that sets my environment variables (P4PORT, P4USER, etc), and runs the necessary p4 commands to sync up my workspace (basically doing the most basic work of the p4 plugin). I turned off the p4 plugin in my job config, and set up this batch file to run as a pre-build step. It worked! Now, this is not a workaround, as it in no way replicates what the p4 plugin can do, but it's an interesting diagnostic step. Basically, I can run p4 by executing a batch file from a slave instance, but I can't connect with the p4 plugin.

If it works from a batch file being executed by the slave agent, then how about this:

@echo off
p4.exe %*

Try creating that and setting it as the perforce executable in the job configuration. If that still doesn't work, try adding the environment variables to the script.

Aha, progress! This approach works, as long as I set P4PORT and P4USER in the script. And I can set the P4TICKETS variable in the script, so I don't have to include a password. I'm not sure why this behaves the way it does, but this is an acceptable workaround. Thank you so much for working with me on this.

Unfortunately, I'm not out of the woods yet. Once the p4 sync happens, I'm getting a "Classloading from system classloader disabled" message which seems to lead to an error invoking MavenModuleSetBuild, and a failure to parse the POM. I'm still researching, but it seems like this is material for a separate JIRA issue, if I can't figure it out.

The plugin will automatically issue a 'p4 login' if it finds it's not authenticated, so you shouldn't need to include P4TICKET.

In any case, that's awesome that you got it working! I'll leave this ticket open in case anyone else runs into it, or someone manages to find the root cause.