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.
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?
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.