[GRADLE-743] search up parent directories to find build.gradle Created: 13/Nov/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.8
Fix Version/s: None

Type: New Feature
Reporter: Philip Crotwell Assignee: Unassigned
Resolution: Won't Fix Votes: 0


I frequently find myself down inside either the src or build directories, and wish to rerun gradle to build the project. Currently if you are in a subdirectory, you get a "FAILURE: Could not determine which tasks to execute." which is a little misleading as the real problem is that there was no build.gradle file in the current directory.

It would be very nice to be able to run gradle from within a subdirectory and have gradle by default search up the directory stack for the build.gradle and then run as if I did a cd to that directory. This would be similar to the settings file "search upwards".

I know the p argument allows something like this, but you still have to know where you are and how many "../"s to put in the arg. If you don't like the idea of gradle searching parent directories by default, then perhaps this could be accomplished by having -p without a following arg or "-pup" mean that gradle searches up the stack.

Just trying to save my dot key from an early death.

Comment by Hans Dockter [ 16/Nov/09 ]

I like this idea. I'm often in the same situation. My little work around is to have a command line alias to switch to the root dir. But of course that is not the same. I'm just wondering about unintended side effects (possibly in conjunction with CamelCase execution. For example you think you are in the source dir of a Gradle project but you are not. Then Gradle goes up the hierarchy and finds a task that does something unwanted. Then again as task usually only does something reproducible re a certain project. So let's implement it.

Comment by Douglas Borg [ 13/Dec/12 ]

I set up a little script for myself to get this behavior and a couple other things.

Check out https://gist.github.com/4278116.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:37:43 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.