Configuration cache requirements vs use-cases

Looking at recent upgrading notes in the Gradle documentation, it seems to me that the Gradle team gradually wants to enforce all configuration cache requirements so that eventually it will work with every project.

What about some plugin use-cases which explicitly make use of the then forbidden restrictions. I’m speaking of plugins which perform project and/or task graph introspection at execution time. For example, printing the task graph in a nice way, or analyzing the module structure during the release process of a muti-product project.

How can such use-cases be realized in the future, or will the support for them just be dropped?

I also assume and hope having CC enabled by default is the future.

If you have a non-covered use-case and there is no issue for it, you should probably open an issue about it, so that the Gradle guys can consider covering the use-case in a compliant way.

Other than that, there is (and I’d assume stays) the possibility to declare a task incompatible with configuration cache. But of course it’s usually better to make it compatible instead if possible.

According to
https://docs.gradle.org/current/userguide/upgrading_version_7.html#task_project
calling Task.getProject during task execution will fail in Gradle 8. This does not say that I cannot inject a project instance in a different way and use that. But the stated reason (configuration cache) points to the possibility that also using a project instance during task execution will be forbidden.

Whether this will really be the case is part of my question. But if it will be, that will be a really hard breaking change. Let’s stick to the prototypical example of rendering a nice representation of the task graph of a project. I do not want to do this at configuration time, even if it is cached somehow. But will this still be possible in a task?

I personally can only guess about that.
But I guess that only the Task#getProject call will be forbidden.
At least only that is, what is deprecated now.
And I actually doubt it will be forbidden in Gradle 8, as it is not really deprecated in 7.4.2 yet.
It is only triggering an error right now if the configuration cache is enabled or if the STABLE_CONFIGURATION_CACHE feature preview is enabled.
Once the feature preview gets stable, it will be deprecated and unless this happens before 8.0 I don’t think it will be made an error.

But ultimately it will probably be made an error, yes.
But at least state of today injecting the project in another way is not yet forbidden, I just tried it.

1 Like