Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why won't gradle run from within a jenkins job

I am trying to setup a build on our Jenkins server to run a fork of the hibernate-core project.

I have been able to get Jenkins to do the git clone to get a local repository from my github fork, but when Jenkins tries to run the 'gradlew' command it fails.

When running this script directly from the checked out folder the build runs as expected, but when launching the script via Jenkins it fails.

The job is configured as a Freestyle configuration with the build step setup as an "execute shell" step.

The build step runs the following command.

./gradlew clean test install buildReleaseBundles uploadArchives --debug --stacktrace

It seems that the gradlew script is being executed but within the gradle Download class something goes wrong.

My build script outputs the following:

Building on master
Checkout:workspace / /data/hudson/jobs/hibernate-envers-stevemac/workspace - hudson.remoting.LocalChannel@63e4f703
Using strategy: Default
Last Built Revision: Revision 7cdb4c829f28c5b029a3d43f50a54d4c89fc9665 (origin/Branch_4.0.0.Final)
Checkout:workspace / /data/hudson/jobs/hibernate-envers-stevemac/workspace - hudson.remoting.LocalChannel@63e4f703
Fetching changes from 1 remote Git repository
Fetching upstream changes from https://[email protected]/stevemac007/hibernate-core.git
Commencing build of Revision 7cdb4c829f28c5b029a3d43f50a54d4c89fc9665 (origin/Branch_4.0.0.Final)
Checking out Revision 7cdb4c829f28c5b029a3d43f50a54d4c89fc9665 (origin/Branch_4.0.0.Final)
[workspace] $ /bin/sh -xe /tmp/tomcat6-tmp/hudson9191971611159378903.sh
+ ./gradlew clean test install buildReleaseBundles uploadArchives --debug --stacktrace
Downloading http://repo.gradle.org/gradle/distributions/gradle-1.0-milestone-3-bin.zip

Exception in thread "main" java.io.FileNotFoundException: /usr/share/tomcat6/.gradle/wrapper/dists/gradle-1.0-milestone-3-bin.zip.part (No such file or directory)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
    at org.gradle.wrapper.Download.downloadInternal(Download.java:46)
    at org.gradle.wrapper.Download.download(Download.java:37)
    at org.gradle.wrapper.Install.createDist(Install.java:54)
    at org.gradle.wrapper.Wrapper.execute(Wrapper.java:80)
    at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:37)
Build step 'Execute shell' marked build as failure
Finished: FAILURE
like image 510
stevemac Avatar asked Jan 03 '12 22:01

stevemac


People also ask

Why is Gradle not working?

In some cases when your Gradle files are deleted or corrupted you will not be able to download new Gradle files in android studio. In this case, we have to delete the Gradle files which are present already and then again sync your project to download our Gradle files again. For finding your .

Does Jenkins support Gradle?

Gradle is managed as another tool inside Jenkins (the same way as Ant or Maven), including support for automatic installation and a new build step is provided to execute Gradle tasks. It also allows detecting Build Scans in arbitrary console logs, for Maven and Gradle builds and display them in the Jenkins UI.

Why does Gradle build fail?

If gradle --version works, but all of your builds fail with the same error, it is possible there is a problem with one of your Gradle build configuration scripts. You can verify the problem is with Gradle scripts by running gradle help which executes configuration scripts, but no Gradle tasks.


1 Answers

As normal with this sort of question, the actual asking of it caused me to re-read the message correctly and look for the result.

And in this case all of the information I needed was there.

FileNotFoundException: /usr/share/tomcat6/.gradle/wrapper/dists/gradle-1.0-milestone-3-bin.zip.part (No such file or directory)

The issue is the user that runs the Jenkins job was not the same user I was running the job on the server as, and the job didn't have write access to the /usr/share/tomcat6/ folder.

Granting write access for the tomcat6 user to /usr/share/tomcat6 allowed this job to run.

like image 146
stevemac Avatar answered Oct 12 '22 13:10

stevemac