The configuration cache is a feature which improves build performance by caching the results of the configuration phase, for reuse in future builds. To accomplish its goals, the configuration cache imposes certain limitations on what can be done during the configuration phase, so it can keep track of all the state of the configuration phase.
One of these limitations is a prohibition on running external processes. Running external processes should be done either as a task action (i.e. deferring to the execution phase), or through configuration-cache-compatible APIs such as ProviderFactory#exec or inside a ValueSource with an injected ExecOperations service.
Unfortunately, GradleUtils currently runs afoul of this limitation, because of JGit. JGit executes the git command (using Java's ProcessBuilder) to gather information about the system-wide git config.
After some investigation, it seems not possible to specifically replace the code in JGit which executes those commands to use the Gradle APIs mentioned above. Therefore, we have to wrap invocations to JGit -- specifically, those which construct a new Repository directly or indirectly -- inside of a ValueSource.
The configuration cache is a feature which improves build performance by caching the results of the configuration phase, for reuse in future builds. To accomplish its goals, the configuration cache imposes certain limitations on what can be done during the configuration phase, so it can keep track of all the state of the configuration phase.
One of these limitations is a prohibition on running external processes. Running external processes should be done either as a task action (i.e. deferring to the execution phase), or through configuration-cache-compatible APIs such as
ProviderFactory#execor inside aValueSourcewith an injectedExecOperationsservice.Unfortunately, GradleUtils currently runs afoul of this limitation, because of JGit. JGit executes the
gitcommand (using Java'sProcessBuilder) to gather information about the system-wide git config.After some investigation, it seems not possible to specifically replace the code in JGit which executes those commands to use the Gradle APIs mentioned above. Therefore, we have to wrap invocations to JGit -- specifically, those which construct a new
Repositorydirectly or indirectly -- inside of aValueSource.