Gradle 4.X tooo parallel, plz fix


(Eric Crahen) #1

Guys, Gradle 4.X parallelism is ruining my life. What is happening? Are task dependencies just a partial ordering over the actions within tasks now?

I have custom task A, it makes some files
I have custom task B, it eats some files

I can’t make this work reliably since gradle keeps trying to delete files and/or run these actions at the same time. I’m just setting org.gradle.parallel=false before I hang myself.

WTF?


(Stefan Wolf) #2

Hi Eric,

did you declare that your custom task A outputs the files and custom task B eats the files? Something like

TaskA extends DefaultTask {
    @OutputDirectory
    File outputDir
}
TaskB extends DefaultTask {
    @Destroys
    File dirToDelete
}

This should make sure that the two tasks run in the desired order. For more information please have a look at the userguide.

Cheers,
Stefan


(Eric Crahen) #3

The docs don’t discuss this in much detail at all, so that link doesn’t help.

I have declared output directories in TaskA
I have declared input directories in TaskB which reads these files, it does not delete.

I am at a loss of what I need to do that at all, if TaskA.dependsOn TaskB. Can I disable whatever feature of gradle it is that wants these very, very, VERY, annoying annotation. If TaskA depends on TaskB I want all of TaskA before TaskB, not part of it?

Is it the case TaskA.dependsOn TaskB is a partial ordering now?


(Eric Crahen) #4

Is there some part of gradle aggressively trying to scrub files from the disk? I want that off too… really un helpful stuff


(Sterling Greene) #5

There has not been any change in meaning to TaskA.dependsOn TaskB. It means that Gradle cannot start executing any actions of TaskA until TaskB is complete.

I think you mean that TaskA has input directories that come from the output directories of TaskB (and TaskA.dependsOn TaskB)?

Would it be possible for you to generate a build scan for the build in question when it has the problem? We would be able to see on the timeline view if TaskA/TaskB are really overlapping or if there’s another task executing at the same time.

If you can’t create a build scan, would it be possible for you to reduce your build into a reproducible example of the problem?

Are any of the tasks marked as @CacheableTask or task.outputs.cacheIf { true }?

Are the output directories shared with any other task? e.g., if TaskB’s output directory was build/classes/java/main, that would overlap with compileJava.


(Stefan Oehme) #6

No, it means the same it has always meant: B must run before A.

If this does not work for you, please provide a reproducible example.