Ric Klaren
added a comment - 2011/May/13 12:10 PM - edited Additional information:
Tested with Jenkins ver. 1.411 (and 1.409)
The master is a linux machine running centos (and jenkins 1.411).
No issues with running gradle jobs on linux slaves (running on remote slaves).
It fails on Windows Server 2003 (on the extra slash in front of the path of the gradlew script)
Running mvn hpi:run with a checkout of the gradle plugin works on the same machine (and also on windows 7)
Executing from a remote master on the same machine fails

Gregory Boissinot
added a comment - 2011/May/16 5:14 PM The Gradle Jenkins plugin doesn't process the Gradle wrapper.
You have to configure the Gradle installation directory in the Jenkins global configuration.
You can also use AutoTools.

I do no quite follow your comment, the point of the gradle wrapper is that it is not necessary to configure a gradle tool in jenkins (unless I misunderstood something).

Further more the setting works on with a linux master combined with a linux slave. In the case of a linux master with a windows slave a superfluous '/' appears in front of the command to run the wrapper. Observe the path to gradlew in the original bugreport:

Ric Klaren
added a comment - 2011/May/17 8:43 AM I do no quite follow your comment, the point of the gradle wrapper is that it is not necessary to configure a gradle tool in jenkins (unless I misunderstood something).
Further more the setting works on with a linux master combined with a linux slave. In the case of a linux master with a windows slave a superfluous '/' appears in front of the command to run the wrapper. Observe the path to gradlew in the original bugreport:
cmd.exe /C "/F:\jenkins-slave\workspace\test-job/gradlew" build && exit %%ERRORLEVEL%%
Like this cmd.exe interprets the command it should run as an option.
My colleague tried with a globally installed gradle but didn't get it to work either (I can check on details).
We currently run the gradle wrapper as a dos batch file without issues.

Matt Callanan
added a comment - 2011/Sep/09 1:07 AM - edited We also have this problem using the Gradle Wrapper option on a Windows slave with a Linux Master...
[api] $ cmd.exe /C /apps/deploy/HudsonServer/war/D:\workspace\WINDOWSSLAVE\workspace\quality\api/gradlew --info clean check && exit %%ERRORLEVEL%%
The specified path is invalid.
Notice the mixed Linux/Windows path.
Problem seems to be in the Gradle plugin src/main/java/hudson/plugins/gradle/Gradle.java line 156:
File gradleWrapperFile = new File(workspace.getRemote(), execName);
For a possible fix, see Wim Rosseel's reply on this for the Groovy Postbuild plugin: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin?focusedCommentId=43713671#comment-43713671
Just a word of warning there!
The post build plugin runs on the manager and doing it as you say will fail if you are working with slaves!
As I found out with my windows manager and mixed windows/linux/solaris slave setup
The best option is to define an extra env parameter in your runtime environment.
Read: in the environment for the user as which you run hudson, e.g. your start script then you can do something link this
def env = System .getenv();
evaluate( new File(env['HUDSON_SCRIPT_DIR']+ "/groovy/postbuild-ci.groovy" ).text);