[JENKINS-15406] When using gradlew, root build script field is not used to locate gradlew

Type: Bug
Resolution: Fixed
Priority: Minor
Component/s: gradle-plugin
Labels:
None
Environment:
gradle plugin 1.20

Similar Issues:
Powered by SuggestiMate

Show

It seems "root build script" is not really well taken when using gradlew.

For instance, I have a git repository having a foo/build.gradle script.
I then set "root build script" to "${WORKSPACE}/foo/"

I would like to execute :

$\{WORKSPACE\}/foo/gradlew

But for now, it is some sort of :

$\{WORKSPACE\}/gradlew -p $\{WORKSPACE\}/foo

I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy

Frédéric Camblor created issue - 2012-10-04 16:20

Frédéric Camblor made changes - 2012-10-04 16:25

Description	Original: It seems "root build script" field is always omitted. For instance, I have a git repository having a foo/build.gradle script. I then set "root build script" to "${WORKSPACE}/foo/" I'm using gradlew. I would like to either execute {code} ${WORKSPACE}/foo/gradlew {code} _or_ execute {code} ${WORKSPACE}/gradlew -p ${WORKSPACE}/foo {code} But for now, it is : {code} ${WORKSPACE}/gradlew {code} which is executed, not using foo/build.gradle script. Not that it isn't related to gradlew since when using a gradle installation, it remains the same. I tried to put ${WORKSPACE}/foo/build.gradle in "Build file" field as a workaround, but it didn't worked either (build script is taken, but with -b, not -p which seems reasonable)	New: It seems "root build script" is not really well taken when using gradlew. For instance, I have a git repository having a foo/build.gradle script. I then set "root build script" to "${WORKSPACE}/foo/" I would like to execute {code} ${WORKSPACE}/foo/gradlew {code} But for now, it is some sort of : {code} ${WORKSPACE}/gradlew -p ${WORKSPACE}/foo {code} I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy
Priority	Original: Critical [ 2 ]	New: Minor [ 4 ]
Summary	Original: Root build script field is never used	New: When using gradlew, root build script field is not used to locate gradlew

Frédéric Camblor made changes - 2012-10-04 16:25

Description

Original: It seems "root build script" is not really well taken when using gradlew.

For instance, I have a git repository having a foo/build.gradle script.
I then set "root build script" to "${WORKSPACE}/foo/"

I would like to execute
{code}
${WORKSPACE}/foo/gradlew
{code}

But for now, it is some sort of :
{code}
${WORKSPACE}/gradlew -p ${WORKSPACE}/foo
{code}

I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy

New: It seems "root build script" is not really well taken when using gradlew.

For instance, I have a git repository having a foo/build.gradle script.
I then set "root build script" to "${WORKSPACE}/foo/"

I would like to execute :

{code}
${WORKSPACE}/foo/gradlew
{code}

But for now, it is some sort of :

{code}
${WORKSPACE}/gradlew -p ${WORKSPACE}/foo
{code}

I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy

Frédéric Camblor made changes - 2012-10-04 16:26

Description

Original: It seems "root build script" is not really well taken when using gradlew.

For instance, I have a git repository having a foo/build.gradle script.
I then set "root build script" to "${WORKSPACE}/foo/"

I would like to execute :

{code}
${WORKSPACE}/foo/gradlew
{code}

But for now, it is some sort of :

{code}
${WORKSPACE}/gradlew -p ${WORKSPACE}/foo
{code}

I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy

New: It seems "root build script" is not really well taken when using gradlew.

For instance, I have a git repository having a foo/build.gradle script.
I then set "root build script" to "${WORKSPACE}/foo/"

I would like to execute :

{code}
$\{WORKSPACE\}/foo/gradlew
{code}

But for now, it is some sort of :

{code}
$\{WORKSPACE\}/gradlew -p $\{WORKSPACE\}/foo
{code}

I think we should define gradlew location (relative to checked out root repository) because for the moment, the only way to workaround the problem is to put gradlew in the root scm hierarchy

Gregory Boissinot made changes - 2012-11-26 21:12

Resolution		New: Fixed [ 1 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]

Nicolas Mongrain-Lacombe added a comment - 2013-09-05 18:37

With Jenkins Gradle plugin 1.23

I specified Ab2edemo as my root build script.

[Gradle] - Launching build.
[Ab2edemo] $ /var/lib/jenkins/jobs/Ab2edemo/workspace/gradlew --stacktrace clean build
FATAL: command execution failed
java.io.IOException: Cannot run program "/var/lib/jenkins/jobs/Ab2edemo/workspace/gradlew" (in directory "/var/lib/jenkins/jobs/Ab2edemo/workspace/Ab2edemo"): error=2, No such file or directory
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
	at hudson.Proc$LocalProc.<init>(Proc.java:244)
	at hudson.Proc$LocalProc.<init>(Proc.java:216)
	at hudson.Launcher$LocalLauncher.launch(Launcher.java:773)
	at hudson.Launcher$ProcStarter.start(Launcher.java:353)
	at hudson.Launcher$ProcStarter.join(Launcher.java:360)
	at hudson.plugins.gradle.Gradle.performTask(Gradle.java:236)
	at hudson.plugins.gradle.Gradle.perform(Gradle.java:118)
	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
	at hudson.model.Build$BuildExecution.build(Build.java:199)
	at hudson.model.Build$BuildExecution.doRun(Build.java:160)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
	at hudson.model.Run.execute(Run.java:1603)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:247)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.lang.UNIXProcess.forkAndExec(Native Method)
	at java.lang.UNIXProcess.<init>(UNIXProcess.java:135)
	at java.lang.ProcessImpl.start(ProcessImpl.java:130)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
	... 16 more
Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure

Nicolas Mongrain-Lacombe added a comment - 2013-09-05 18:37 With Jenkins Gradle plugin 1.23 I specified Ab2edemo as my root build script. [Gradle] - Launching build. [Ab2edemo] $ / var /lib/jenkins/jobs/Ab2edemo/workspace/gradlew --stacktrace clean build FATAL: command execution failed java.io.IOException: Cannot run program "/ var /lib/jenkins/jobs/Ab2edemo/workspace/gradlew" (in directory "/ var /lib/jenkins/jobs/Ab2edemo/workspace/Ab2edemo" ): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041) at hudson.Proc$LocalProc.<init>(Proc.java:244) at hudson.Proc$LocalProc.<init>(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:773) at hudson.Launcher$ProcStarter.start(Launcher.java:353) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.plugins.gradle.Gradle.performTask(Gradle.java:236) at hudson.plugins.gradle.Gradle.perform(Gradle.java:118) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1603) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.<init>(UNIXProcess.java:135) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022) ... 16 more Build step 'Invoke Gradle script' changed build result to FAILURE Build step 'Invoke Gradle script' marked build as failure

Nicolas Mongrain-Lacombe made changes - 2013-09-05 18:37

Resolution	Original: Fixed [ 1 ]
Status	Original: Resolved [ 5 ]	New: Reopened [ 4 ]

Denis Zhdanov added a comment - 2013-11-23 21:32

Hello,

Encountered that bug today. Checked jenkins gradle plugin sources and provided a fix - please check this pull request

Regards, Denis

Denis Zhdanov added a comment - 2013-11-23 21:32 Hello, Encountered that bug today. Checked jenkins gradle plugin sources and provided a fix - please check this pull request Regards, Denis

SCM/JIRA link daemon added a comment - 2014-04-06 21:23

Code changed in jenkins
User: denis.zhdanov
Path:
src/main/java/hudson/plugins/gradle/Gradle.java
http://jenkins-ci.org/commit/gradle-plugin/19a81cfa7f1ee6073a0b589811cba61e9763c569
Log:
[FIXED JENKINS-15406]

Use gradle wrapper from a project which is located not at the workspace root

SCM/JIRA link daemon added a comment - 2014-04-06 21:23 Code changed in jenkins User: denis.zhdanov Path: src/main/java/hudson/plugins/gradle/Gradle.java http://jenkins-ci.org/commit/gradle-plugin/19a81cfa7f1ee6073a0b589811cba61e9763c569 Log: [FIXED JENKINS-15406] Use gradle wrapper from a project which is located not at the workspace root

SCM/JIRA link daemon made changes - 2014-04-06 21:23

Resolution		New: Fixed [ 1 ]
Status	Original: Reopened [ 4 ]	New: Resolved [ 5 ]

Assignee:: Gregory Boissinot

Reporter:: Frédéric Camblor

Votes:: 2 Vote for this issue

Watchers:: 6 Start watching this issue

Created:: 2012-10-04 16:20

Updated:: 2022-10-27 09:45

Resolved:: 2014-04-06 21:23

Jenkins

Details

Description

Attachments

Activity

Collapse comment: Nicolas Mongrain-Lacombe added a comment - 2013-09-05 18:37

Expand comment: Nicolas Mongrain-Lacombe added a comment - 2013-09-05 18:37

Collapse comment: Denis Zhdanov added a comment - 2013-11-23 21:32

Expand comment: Denis Zhdanov added a comment - 2013-11-23 21:32

Collapse comment: SCM/JIRA link daemon added a comment - 2014-04-06 21:23

Expand comment: SCM/JIRA link daemon added a comment - 2014-04-06 21:23

People

Dates