Gradle still runs disabled tasks

Help/Discuss
1

I’m pretty sure this is a bug, but I’m wondering if maybe this behaviour is documented somewhere and I haven’t seen it, or whether someone can explain it first.

For this script

apply plugin: 'cpp'

model {
    
    toolChains {

	visualCpp(VisualCpp) {

        }

    }

    components {

        TestProject(NativeLibrarySpec) {

        }

    }

}

tasks.matching { it.name == 'assemble' }.all { enabled = false }

Forgive my using native - they’re the only components I’m familiar with, but I don’t believe this is native-related.

Output of gradle build

:linkTestProjectSharedLibrary UP-TO-DATE
:TestProjectSharedLibrary UP-TO-DATE
:createTestProjectStaticLibrary UP-TO-DATE
:TestProjectStaticLibrary UP-TO-DATE
:assemble SKIPPED
:check UP-TO-DATE
:build UP-TO-DATE

Output of gradle assemble

:linkTestProjectSharedLibrary UP-TO-DATE
:TestProjectSharedLibrary UP-TO-DATE
:createTestProjectStaticLibrary UP-TO-DATE
:TestProjectStaticLibrary UP-TO-DATE
:assemble SKIPPED

In part, I’m not sure how the build sequence is structured - I’ve been trying to interrogate every property on the Task class to find out how it references the other tasks, but I’ve yet to find anything useful in dependsOn, taskDependencies, mustRunAfter or shouldRunAfter, but I might just not know how where to look, so any advice here would be appreciated.

However, to my question at hand - why does Gradle execute the task ‘assemble’ in my example both from the command-line and as part of the build task?

I can reproduce this with a lot of other tasks, but this was the simplest example I could generate.

Thanks,

Phil

2

Gradle is not executing the assemble task, that’s why it says ‘SKIPPED’. Disabling a task does not change the task graph, so it still exists in the task graph and its dependencies will still be executed.

3

Thanks Chris.

Is there a state into which I can put a task where Gradle won’t execute its
dependencies? That’s what I was hoping for from disabled, in truth.

Or, could you point me in the right direction of the right functions to
call to find, in this example, assemble’s references to those other tasks?

Regards.

4

There is no such task state that I’m aware of. I’m guessing you could rig something up by processing the assemble task’s dependencies. However, I’m not really sure why you would want to do what you are asking. It sort of goes against the general philosophy of Gradle, which is to always execute the entire task graph, but do so in an optimized fashion (ie. task input and output checking, aka UP-TO-DATE tasks). When I say “entire task graph”, I only mean the task graph required to reach the tasks you requested on the command line, I don’t mean all tasks defined in the project.

Going back to one of of your original questions:

Gradle executes the assemble task because build depends on it. The build task is generally a shortcut for “create my binaries and run my verification/tests”. “Create my binaries”, is represented by assemble and “run my verification/tests” is the check task. If you run the check task you should see that it also depends on tasks that create the binaries.

5

Apologies, I didn’t do a very good job of phrasing my question. In my original case (not highlighted here), I was trying to disable a tree of tasks generated by the visual-studio plugin that I didn’t want, and it would have been ideal if disabling the lifecycle task at the head of that tree had meant that none of them were executed, but it’s confusing when Gradle still reads the dependencies of a disabled task and executes them.

I was hoping that disabling a task would either have it not called by its dependencies at all, or at least not call its own dependencies.

I can work around it, of course, for the few scenarios where there are generated tasks which I don’t want, but it was confusing behaviour.

Regards,

Phil

6

Hi Phil,

As it was already mentioned, Task.enabled will only disable the current task and not it’s dependencies. This is the expected behavior. To disable a tree of task, you will need to manually walk the graph by visiting Task.getDependsOn as well as Task.getFinalizedBy and disable each one. Care must be taken to prevent disabling tasks that, for some reason, are referenced in your dependency tree. For example, if a custom task depends on a tooling binary that is required to build before the custom task. Disabling such a task by blindly walking the tree may result in disabling more task than expected.

I hope this helps,

Daniel

1 Like