"Soft" Task Dependencies


(andrew.oberstar) #1

Would it be possible to have a way to declare a “soft” dependency between tasks. What I’m getting at is that if taskA has a soft dependency on taskB, taskA would always run after taskB, but running taskA wouldn’t require taskB to run.

My use case for this is test and integTest tasks. Since they don’t have a dependency between them they run in alphabetical order which means my integration tests run before the unit tests. I’d rather only run integration tests if the unit tests succeed, but still have the option to run integration tests separately (without having to explicitly exclude them).

If you have any other ideas on how best to handle this, I’d appreciate it.


(Szczepan Faber) #2

It is somewhat related to GRADLE-427

We’re are considering a couple of ways of solving your use case.

My personal preference is making dependsOn ‘hint’ the order to the graph optimizer (just like the command line task list). However, the final decision hasn’t been made yet.

In meantime you can run your build via ./gradlew check integTest :slight_smile:


(andrew.oberstar) #3

Thanks, I remember seeing that ticket before.

WIth your approach and the test and integTest tasks, wouldn’t I need to edit the dependsOn order of the check task? That seems like an odd way to configure it.

What I’m really trying to say is that there’s a natural ordering between these two tasks. I guess you could think of it like a compareTo in a sense. integTest should always come after test, but neither of them necessarily has to be there.


(Szczepan Faber) #4

With your approach and the test and integTest tasks, wouldn’t I need to edit the dependsOn order of the check task? That seems like an odd way to configure it.

You’re right, it is a bit odd. There are other ideas how to resolve that use case, for example make the optimizer smart enough to run faster tasks earlier; provide DSL for configuring task order hints; or adding graph.beforeReady hooks to influence the optimizer, etc.


(Adam Murdoch) #5

I would rather that Gradle can just figure this ordering out, without you having to specify anything.

My preferred option is that Gradle, by convention, tries to run verification tasks as quickly as possible. Both ‘test’ and ‘integTest’ are an instance of VerificationTask, by virtue of having type Test. Gradle would use a heuristic to decide how to order the tasks:

  • Order the tasks based on historical execution time, so that the fastest tasks run first. * Order the tasks based on how much work is required to meet their dependencies. Tasks with fewer dependencies would run first.

We would generalise this into a “run as early as possible” and “run as late as possible” capability, which would also be useful, for example, for running validation tasks early in the build, or upload tasks late in the build.

Having said that, I think a “runs before” or “runs after” relationship that you could attach between tasks would be very useful as well. So, another option is certainly to have a way to specify “test runsBefore integTest”. We could then introduce an integ-test plugin, which sets up the integTest task, and adds the relationship for you.