Configuration Cache and External System Property Access

Hi all,

I need some guidance on how to make my plugin configuration-cache friendly.

For work, I created a Gradle plugin that automatically writes a Git hook when it is applied (for those who are familiar with the NPM ecosystem, think like husky). The way I do this is by looking up the hook which should be configured from an extension and comparing what the current hook is (if one exists) with what should be written. To ensure the extension value is available, I run all of this in an afterEvaluate block.

Right now, all of this happens during configuration time (and seems to be fast enough). However, the code uses Freemarker templates, and when creating one of its Configuration objects, a method is called that reads the “file.encoding” property. I don’t have an opportunity to tell it to use a value I can extract from a provider returned by the systemProperty() method. So my direct question is regarding how to deal with this scenario.

All of this has also made me reconsider whether this logic should be part of the configuration of the build. Perhaps this should be a task, but is it then possible to always run this task before user selected tasks?

Thank you to anyone who takes the time to read this, and even more if you have suggestions.

Hi Theodore,

Moving the processing to a task would move the system property read to execution and satisfy configuration cache constraints. It would also be better as it would move the “expensive” processing out of configuration time.

That being said, there’s currently no way to tell Gradle that a library used at configuration time will read a given system property. In other words, you can’t remove the reported configuration cache problem and users would have to rely on using --configuration-cache-problems=warn. The thing you can do now is to declare the system property read using providers.systemProperty() so that the configuration cache has the opportunity to invalidate its cache in the event that property value changes. It’s quite unlikely with file.encoding though.

That’s how things are at this stage. We are aware of the issue and will get to provide construct to handle this use case.

Related issue https://github.com/gradle/gradle/issues/13676