Monthly Archives: January 2010

Hudson

Hudson Perforce Plugin error: no output for command

8 Comments
Last night, we restarted one of our Hudson nodes and started getting the following error when trying to run a Perforce build:
Started by user vaustje
Building remotely on node4
Using remote perforce client: SOME_CLIENT
Caught exception communicating with perforce. No output for: p4 workspace -o SOME_CLIENT
com.tek42.perforce.PerforceException: No output for: p4 workspace -o SOME_CLIENT
at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:314)
at com.tek42.perforce.parse.Workspaces.getWorkspace(Workspaces.java:53)
at hudson.plugins.perforce.PerforceSCM.getPerforceWorkspace(PerforceSCM.java:671)
at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:294)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1003)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:428)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:376)
at hudson.model.Run.run(Run.java:1174)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:303)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:123)
Finished: FAILURE
While we first suspected that there was an error running the p4 command on the remote machine, it turned out that p4 was not getting executed at all. What happened was, before restarting the node we had changed the .bashrc file and accidentally removed the location of our p4 executable from the path. Then, when the node was restarted the Hudson executor could no longer find the executable and thus failed with a very unintuitive message. (For some reason, specifying the explicit path to the executable via “Path to p4 executable” in the job config had no effect–see this JIRA issue) After fixing the PATH variable on the machine and restarting, our issue was resolved.
In general, you can check the value of the PATH variable, and other variables, on the Hudson nodes by going to Hudson » nodes » nodename and clicking on Log.
Maven

405 Error when deploying to Maven Repository

7 Comments
If you’re getting a 405 error when trying to deploy a file to your Maven repository, it’s because the URL (as in -Durl=http://host.com/repo) you have specified is somehow incorrect.

For example, I was trying to deploy a file using the mvn deploy:deploy-file target to a Nexus repository, and I got the following error:

$ mvn deploy:deploy-file -DgroupId=com.austje.test -DartifactId=project -Dversion=1.0 -Dpackaging=jar -Dfile=project.jar -Durl=http://repo1.austje.com/ -DrepositoryId=MyReleases
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [deploy:deploy-file] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [deploy:deploy-file {execution: default-cli}]
Uploading: http://repo1.austje.com//com/austje/test/project/1.0/project-1.0.jar
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file: http://repo1.austje.com//com/austje/test/project/1.0/project-1.0.jar. Return code is: 405
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Jan 25 11:15:25 CST 2010
[INFO] Final Memory: 5M/9M
[INFO] ------------------------------------------------------------------------
Looking at the line Uploading: http://repo1.austje.com//com/austje/test/project/1.0/project-1.0.jar, it’s pretty obvious that my url is wrong–that’s not where the artifact should be uploaded at all. Turns out I gave the repository server, but not the actual repository url! Changing my url parameter to reflect this

$ mvn deploy:deploy-file -DgroupId=com.austje.test -DartifactId=project -Dversion=1.0 -Dpackaging=jar -Dfile=workingTest.zip -Durl=http://repo1.austje.com/nexus/content/repositories/my-repo/ -DrepositoryId=MyReleases
fixed the issue, and I was able to deploy successfully.
Of course, this is not the only way you could screw up the url parameter. Among many possibilities, one tricky one I’ve seen is using http instead of https as the protocol.
Extra tip: If you fix the URL and are now getting return code 401, your credentials are incorrect. Try fixing them in your settings.xml file. You can test the credentials by going to the Nexus GUI and logging in. If those work, and you’re still not able to deploy via the command line, make sure the <id> in your <server> section of your settings.xml matches the <id> in the corresponding <repository> element.