-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Windows
When there is an error in the global configuration that injects broken environment variables (blank name for the variable) the Perforce-plugin fails with:
Started by user testuser
[EnvInject] - Loading node environment variables.
Building remotely on testslave in workspace E:\build_e\workspace\Test_Component
Using remote perforce client: testclient-12345678
[Test_Component] $ C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
Caught exception communicating with perforce. No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678 com.tek42.perforce.PerforceException: No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:384)
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292)
at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:61)
at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1528)
at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:1489)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:795)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468)
at hudson.model.Run.run(Run.java:1408)
at hudson.model.Build.run(Build.java:110)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
ERROR: Unable to communicate with perforce. No output for: C:\apps\perforce\p4.exe workspace -o -S //test/test_stream testclient-12345678
Finished: FAILURE
The correct error would be something like, can't "run the command".
Because the actual error is something like:
Caused by: java.io.IOException: Cannot run program "cmd.exe" (in directory "E:\build_e\workspace\Test_Component"): CreateProcess error=87, The parameter is incorrect
at java.lang.ProcessBuilder.start(Unknown Source)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
[JENKINS-15904] Perforce plugin issues wrong error message when exception occurs on remote end
The error handling completely hides certain types of errors, and just says 'No output for...'
src\main\java\com\tek42\perforce\parse\AbstractPerforceTemplate.java:
throw new PerforceException("No output for: " + debugCmd);
| Summary | Original: Perforce plugin issues wrong error message when it can't start cmd.exe to run p4.exe | New: Perforce plugin issues wrong error message when exception occurs on remote end |
Updating ticket summary, since this is a pretty general problem it seems. It's not so much that it's 'hiding' errors, as it can't send exceptions back from the remote slave agent using the current implementation. The only notion that the master has that something is wrong is the lack of data being returned.
I'd like to know how you are able to view the actual exception. It may help us find a way to transfer that exception back to the master and report it correctly.
Our engineers are trying to isolate from our private branch the changes needed to show the actual exception.
It basically catches the possible errors in calling the command.
Exploratory diagnostic patch: https://github.com/jenkinsci/perforce-plugin/pull/34
Regarding https://github.com/jenkinsci/perforce-plugin/pull/34#issuecomment-24535270 discussion, is there still a problem with RemoteLauncher in current versions of Jenkins, and if so is this filed?
We need the streams to be closed correctly after the command has finished executing and this was not happening on slaves back then, which is part of what prompted me to re-implement it.
I don't believe it's an issue in current versions, but I could be mistaken. I haven't had the chance to try it again.
In any case, we still support pre-fork versions of Hudson, so the current code will likely need to stay put for now... We might just need to catch any IOExceptions in the RemoteCall, and pass them back over the channel by hand.
Where are you seeing the actual error?