-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Hudson master on Linux, Slave on Windows XP
Starting a job using the Gradle Wrapper on a windows machine leads to an invallid command for Windows.
This is the output:
Started by user bjansen Building remotely on ******* Updating http://****** At revision 48667 no change for http://******* since the previous build [test-job] $ cmd.exe /C "/F:\jenkins-slave\workspace\test-job/gradlew" build && exit %%ERRORLEVEL%% The filename, directory name, or volume label syntax is incorrect. Notifying upstream projects of job completion Finished: FAILURE
The part /F:\jenkins-slave\workspace\test-job/gradlew should be corrected
[JENKINS-9553] Gradle wrapper command fails on Windows
Gregory Boissinot
added a comment - 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.
Gregory Boissinot
added a comment - 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. 
Ric Klaren
added a comment - 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.
Ric Klaren
added a comment - 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. 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);
Matt Callanan
added a comment - - 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);
Ric Klaren
added a comment - I did a stab at fixing this. Just issued a pull request on github. Hope I got things ok. Wil retest tomorrow on our companies jenkins installation.
Ric Klaren
added a comment - I did a stab at fixing this. Just issued a pull request on github. Hope I got things ok. Wil retest tomorrow on our companies jenkins installation. Code changed in jenkins
User: Ric Klaren
Path:
src/main/java/hudson/plugins/gradle/Gradle.java
http://jenkins-ci.org/commit/gradle-plugin/6630df28bed25b5b6d5b95cbc09556e388b180f4
Log:
Fix for JENKINS-9553: use FilePath to build path to gradle wrapper on slave
Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/hudson/plugins/gradle/Gradle.java
http://jenkins-ci.org/commit/gradle-plugin/19fb74b5c9e19c57e647abd2f7fabd7299b82a78
Log:
Merge pull request #4 from rklaren/master
Bugfix for JENKINS-9553 tested on Jenkins 1.435, linux master <> windows 7 slave and linux master <> linux slave on master. Please double check since I'm not familiar with jenkins coding 
Compare: https://github.com/jenkinsci/gradle-plugin/compare/f2e46e4...19fb74b
Additional information: