Take the 2-minute tour ×

Having an extract from https://github.com/gradle/gradle/blob/master/build.gradle:

ext {
  isDevBuild = {

task developerBuild {
  description = 'Builds distributions and runs pre-checkin checks'
  group = 'build'
  dependsOn testedDists

When I used this approach to create custom configuration in my project I discovered that:

isDevBuild === true

i.e. it's always true because task 'developerBuild' is inside my build.gradle project, and hence in graph. They have a couple of "different" configs (isCIBuild, isCommitBuild, isFinalReleaseBuild, ...) so I suppose I got something wrong here.

Can someone explain how to make this configs conditional based on some external parameter?

share|improve this question

1 Answer 1

up vote 17 down vote accepted

taskGraph.hasTask() tells if a task is in the task execution graph, that is whether it will get executed. Because the task execution graph is only created after the configuration phase, this method has to be called from a whenReady callback (or in the execution phase):

gradle.taskGraph.whenReady { graph ->
    if (graph.hasTask(developerBuild)) { 
        // do conditional configuration

To make this more readable, we can introduce a new method:

def onlyFor(task, config) {
    gradle.taskGraph.whenReady { graph ->
        if (graph.hasTask(task)) { 
            project.configure(project, config)

Now we can write:

onlyFor(developerBuild) { ... }
onlyFor(ciBuild) { ... } 

Another, simpler way to solve this problem is to check whether a particular task name is contained in gradle.startParameter.taskNames. However, this has two limitations: First, it compares task names, which can make a difference in multi-project builds. Second, it will only find tasks that have been specified directly (e.g. on the command line), but not dependencies thereof.

PS.: In your code, isDevBuild always holds because a (non-null) closure is true according to Groovy truth. (In contrast to isDevBuild(), isDevBuild won't call the closure.)

share|improve this answer
Going back to assertion from the "Building and Testing with Gradle" book: knowledge of Groovy is not plus - it's a must to start to work with Gradle. Thanks for your help. Will check it later today. –  Artem Oboturov May 11 '12 at 17:55
I wouldn't say it's a must to get started, but it's necessary to implement advanced solutions like this one. (A simple alternative which requires less Groovy knowledge is to switch between different configurations based on a system property.) Then again, much of this code could be written in Java style (with anonymous inner classes and such), or literally in Java if you moved it into a plugin. The real challenge in this particular case is to understand the Gradle side of things: the task graph API, configuration vs. execution phase, etc. –  Peter Niederwieser May 11 '12 at 18:29
Your solution works well. Thanks a lot. For the note you put in P.S. : I can not directly call isDevBuild() when I execute Gradle build with ciBuild jar for example (and I can not use both configs in same time) - although you showed that I can call closure only for educational purposes. –  Artem Oboturov May 14 '12 at 8:43
Thanks to take a look at question at SO: not all lead developers commit their time for community support. –  Artem Oboturov May 14 '12 at 8:59

Your Answer


