Is there a way in gradle to "link" 2 tasks so that if one runs, the other is always forced to run too? The problem I have is I have a task that configures compileGroovy , so when something triggers compileGroovy to run, I need to make sure my task isn't loaded from cache. I tried depending on the runtimeClasspath - but then any task that changes that task, my task needs to declare a dependency or gradle will fail (complains about an explicit depndency is required). Ideally, I'd use doFirst { } in the groovy compile step, but I can't because it could actually be N+1 tasks that need to run before compileGroovy. Was hoping to avoid just disabling caching on that task - i don't want it to run over and over unless it has to.

The problem I have is I have a task that configures compileGroovy

Yes, that is a problem. 🙂 You should not configure a task from execution phase. Neither the own task, nor another task. With configuration cache this might even be forbidden or at least not work as expected. Maybe the best solution to your problem which appears to be an XY problem would be to share your concrete use-case, so that a proper solution to your actual use-case can be provided. 🙂

so when something triggers compileGroovy to run, I need to make sure my task isn't loaded from cache.

Just have

compileGroovy

dependsOn

the configuration task but better don't need this at all, see above. Your configuration task will never be served from cache, as tasks are never cacheable by default, so unless you configure your task to be cacheable it will never be cached and as it also does not have inputs or outputs it will also never be up-to-date.

I tried depending on the runtimeClasspath - but then any task that changes that task

Not sure what you talk about,

runtimeClasspath

is not a task but a configuration.

complains about an explicit depndency is required

That is usually a sign that you do not properly wire task outputs to task inputs or do something else you really shouldn't do. Despite the "recommendation" in that error it is practically never the right solution to add an explicit task dependency or ordering constraint but instead to fix the actual underlying problem.

Ideally, I'd use doFirst { } in the groovy compile step

That would still be changing configuration from execution phase and is even worse than having a "configure task" that configures a different task. Looong ago it was a common pattern to do configuration in

doFirst

but this is also for looong discouraged bad practice and such a "configure task" was the common replacement, which in the meantime also became discouraged bad practice, latest when you strive to become configuration cache compatible.

The core issue is I need to configure the groovy compiler, but it only takes a file as it's configuration script - and that script could have been configured by the end user in their build script. I need to configure groovy so i can inject metadata so the AST transforms know what to do during compilation based on the metadata (if it's an application vs a plugin).

groovy compiler ??

You would have a task to generate the required file(s) and wire the task's output to the groovyCompile inputs (either add them to the sourceSet's sources, or the task's astTransformationClasspath; I don't think GroovyCompile has an equivalent to JavaCompile's options.compilerArgumentProvider though, in case you'd need to pass the files as argument to the groovy compiler); that should be enough for Gradle to infer the task dependencies.

👍

The core issue is I need to configure the groovy compiler, but it only takes a file as it's configuration script

Ah, ok, I thought you meant changing Gradle configuration. Generating a file that the Groovy compiler uses is fine of course and that could of course also be cacheable if the generation of that file is super expensive (caching also has an overhead). But then I don't get where the problem is. The

groovyOptions.configurationScript

is not yet a

RegularFileProperty

, but only accepts a

File

, so cannot carry on the task dependency yet, this changes in Gradle 10 hopefully. So as the

configurationScript

is already an input file but you miss the task dependency, indeed here a

dependsOn

on the generation task would be the proper work-around.

I don't think GroovyCompile has an equivalent to JavaCompile's options.compilerArgumentProvider though

Sure it has.

groovyOptions.forkOptions.jvmArgumentProviders

But actually for the configuration script there is a dedicated setting it just does not accept providers yet.

Has this version released in last update /version

For Grails? No, not yet