Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: gradle-plugin
-
Labels:None
-
Environment:Hudson master on Linux, Slave on Windows XP
-
Similar Issues:
Description
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
Attachments
Activity
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:
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);
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: