From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

If the start parameter is `--no-configuration-cache`, yes :smile:

Besides that, you can probably take any task from the task graph if your condition holds and call `notCompatibleWithConfigurationCache()` on it.

Actually I need `ResolvedComponentResult` because I want to look at the dependencies.

AFAIK this will be possible with 7.4:
<https://github.com/gradle/gradle/pull/19639>

Also you might want to check this demo project how to use it in configuration cache compatible way:
<https://github.com/adammurdoch/dependency-graph-as-task-inputs>

Ok thanks that’s great new. I only found the ‘revert’ and some comments that it is not yet ready. Guess I looked in the wrong places.
I’ll try it out tomorrow and report.

Seems to work. :+1: We don’t have configuration cache enabled yet in that project, so I didn’t test it yet with config cache on.

This seems like an issue on Jetbrains's side, you're probably better served by the Kotlin slack, there's a #code-coverage channel.  Unless this is about the "incremental" configuration cache feature.

`notCompatibleWithConfigurationCache()` will make the problems to _not_ fail the build and disable CC but the problems are still reported

`koverMergedHtmlReport` is not the only task that has problems, you should mark the others as not compatible

I added the following but it still fails the build
```listOf(
    ":koverMergedHtmlReport",
    ":koverMergedXmlReport",
    ":koverVerify",
    ":utils:common:koverVerify",
    ":utils:common:test",
).forEach {
    tasks.getByPath(it).notCompatibleWithConfigurationCache("Don't know")
}```

looks like I missed one! `:koverMergedVerify` perhaps the error message should specify which problems were ignored and which weren’t.

I filed a feature request with Kover: <https://github.com/Kotlin/kotlinx-kover/issues/142>

The property might be mutated by the build itself at the configuration phase, this isn't well handled
The issue is tracked at <https://github.com/gradle/gradle/issues/19710>

thank you for issue and workarounds. :thumbsup: I somehow failed to find this issue in gradle repo yesterday. But it is exactly same issue

Task input comparison does not capture changes to the configuration cache inputs.

himm that might explain but in any case I dont expect  headless value to change

<https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements|Documentation> says
```A task input or output property or a script variable to capture the result of using project.rootDir to calculate the actual parameter.```
But isn't that going to break build cache if the input ends up being an absolute path?

I was thinking how to get there from
<https://docs.gradle.org/current/javadoc/org/gradle/api/file/ProjectLayout.html#getProjectDirectory--|https://docs.gradle.org/current/javadoc/org/gradle/api/file/ProjectLayout.html#getProjectDirectory-->

I've been told that rootDir is immutable and therefore safe from a cross-project perspective

`projectLayout.getProjectDirectory()` isn't exactly what I want, I want the directory of the root project and this is not available in `ProjectLayout` or `ObjectFactory` . The closest I could find is make it relative and store it as a string input property:
During configuration:
```task.projectRootDir.set(project.rootDir.relativeTo(project.projectDir).path)```
And then in the task:
```val rootDir = projectLayout.projectDirectory.asFile.resolve(task.projectRootDir)```
But that sounds like going through a lot of hoops

What don't you like with an absolute path? At least currently the configuration cache is not relocatable anyway.

Exactly, I understand build cache will not like different String inputs on different machines

I'm slow now, but if the root directory is a File/Directory input you can use Normalization, don't you?

What is breaking my mind is..what you want to access to the rootProjectDir from a task in a subProject?

I mean, if you are looking for a config file, you can get the File directly (optionally with a provider)

Ah, build cache, yeah, that is problematic for a string-typed input of course.
But noone said you need to have the input string-typed :slightly_smiling_face:

&gt;  if the root directory is a File/Directory input you can use Normalization
You mean the <https://docs.gradle.org/current/userguide/build_cache_concepts.html#normalization|path sensitivity> stuff? I don't really think it applies there. I don't really want an `@InputDirectory` on the root project dir or it's going to snapshot the whole project :sweat_smile: . And `@InputFile` is not going to work either I believe

&gt;  what you want to access to the rootProjectDir from a task in a subProject?
This is a long story. The reason is mostly historical. We have a task that only takes input from the command line and one of them is a path. Initially, we had that path resolved relative to the current working directory but we found that in a few occasions, the cwd wasn't reliable (sometimes it was the cwd of the daemon and not the directory where `./gradlew` was run in). So the next choice was to use the directory where `./gradlew` is and most of the times it's the root project directory

Then maybe make it an internal `Directory` property and construct the actual `@Input...` property from that and the user input, because that is your actual input?

That could work! Only using `rootProject` during configuration indeed :thumbsup:

InputFile with PathSensistivity.Relative wouldn't work? Would the snapshot be the full filetree?

Iirc you cannot use input file with a directory, what should that do?
And it also works not really be correct for his use-case.

<https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/PathSensitivity.html|PathSensitivity documentation> is all about file collections so not sure that'd work with a single `File` . Also not sure what Gradle would do if I put a `@InputFile` on a directory. Maybe it uses the absolute path as content to be snapshot but then I might as well use a string..;;

I was thinking a File can be either file or directory, so it should be fine used with Path sensitivity relative.

But yeah, the internal + string input seems perfectly fine.

What would it be relative to if it's a single File?

Like any file. I don't know if that's to project or root.. :thinking_face:

My understanding of <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/PathSensitivity.html#RELATIVE|the doc>
``` For files in directories in the root of the file collection, the normalized path is the relative path of the file to the root directory containing it.```
is that `PathSensitivity.RELATIVE` is mainly for `SourceDirectorySet`where you can call `srcDir` to add root directories

Path sensitivity should work fine for `@InputFile` and have the same effect as on `@InputFiles` for example.
But as I said, I believe configuring a directory for an `@InputFile` will result in an error and if it does not, it should as it just does not make sense.

I have some plugin code that I need to migrate away from this API due to it now being deprecated.

The code in question gathers information from this callback during the build and generates some reporting t the conclusion of the build (via the also deprecated `buildFinished` hook)

I'm currently digging into task outputs to get report dirs, etc., as part of the data gathering so I actually want the `Task` instance

I suppose I could resolve this by adding task finalizers to all impacted tasks and then feed that info into a build service but am hoping not to do this due to the sheer volume of tasks that would be added to our already insanely large task graph...

(side note: what would be really awesome is to be able to append an Action to a task that runs even on prior action failure)

• create a build service
• make it implement `OperationCompletionListener`
• inject an instance of `BuildEventsListenerRegistry`
• use the latter to register the former for being informed about finish events
• make the build service implement `AutoCloseable` to have a conform replacement for `buildFinished`

That approach doesn't give me access to the `Task` implementations, unfortunately

(well, if it does, I don't see the connection...)

Could be that it doesn't and that this is not supported.
Just some speicific information like outcome, starttime, endtime, ....
If you have a valid use-case you might post a feature request, maybe they can add something.

Roger that.  I haven't seen an appropriate API but was fishing here to see if I missed anything.

I imagine they don't want to expose `Task` since it is mutable and _could_ be used to change something that would impact configuration-time.

yeah `Task` is a mutable object that comes with a lot of baggage. the whole point is to not expose `Task` and friends

still waiting on an alternative for  `beforeTask` myself

Hey Tony, we’re definitely missing better reporting but a `UnsupportedRepositorySpec` there means the repository is not `file://` based.

is it this section and, if so, can you tell me how to fix it?
```ext.isSnapshot = version.toString().endsWith('-SNAPSHOT')

publishing {
  repositories {
    maven {
      name = artifactoryRepoName

      def releasesUrl = 'https://&lt;&lt;square&gt;&gt;/artifactory/releases/'
      def snapshotsUrl = 'https://&lt;&lt;square&gt;&gt;/artifactory/snapshots/'
      url = isSnapshot ? snapshotsUrl : releasesUrl```

I’m afraid publishing to remote repositories is not yet supported by the configuration cache :/

<https://github.com/gradle/gradle/issues/13468>

ohhhh got it. I'll mark all those tasks as incompatible, then

the CC report should link to that issue :slightly_smiling_face:

shouldn't this work?
```tasks.withType(PublishToMavenRepository).configureEach {
  notCompatibleWithConfigurationCache('See <https://github.com/gradle/gradle/issues/13468>')
}```
I get the same error report, though.

reports are still generated for `notCompatibleWCC` tasks

oh derp. The issue was that I had another CC issue that I'd fixed in a separate PR, so it was failing on _that_. Serves me right for trying to do focused PRs, one issue at a time :sweat_smile:

Is ditching the idea of configuring things in the root build.gradle and switching to gradle properties instead the way to go here?

Hi Eric,
We're working on designing replacements for `allprojects {}` and such for central configuration that will work with project isolation but nothing ready as of Today. In the current state of project isolation, using Gradle properties would work.

In this specific case, maybe using a settings plugin (configuring the extension in settings.gradle rather than the root build.gradle) would work (and possibly using a build service to share that value across projects) ?

Using a build service to share the state should also work yes

It could be configured from settings or from the root project. The root project is always configured first. Moving the configuration to settings would make more sense to me though as it looks like what you're doing Eric is a global _setting_ for the whole build :thumbsup:

Update: switched over to a settings plugin + build service and the result is perfect. Thanks again!

huh. The chain has an NPE in both the _real_ and _test_ cases, but only fails CC for the latter. That's odd

with configuration cache, does gradle have to resolve all `Provider&lt;RegularFile&gt;` inputs at configuration time?

My rough understanding is that if a provider resolves to a fixed value post-configuration then that value gets serialized, rather than the provider itself (but often it doesn't, e.g. if you wire a task output to an input the value will only be known at execution time). So maybe a value somewhere in the chain is fixed post-configuration in your test but not in your real usage? <https://github.com/gradle/gradle/blob/a7ed5ebdd4bbbcb02b7323e418acc0998abc27aa/subprojects/model-core/src/main/java/org/gradle/api/internal/provider/ProviderInternal.java#L54-L66>

I have observed that in both the real and test situations, the provider is being queried at configuration time, when the final value is not ready yet (in fact the final value is a file that doesn't exist until execution time). I haven't yet found anywhere where I might be querying this value early.

looking at the stack traces, it's gradle all the way down. I'm not seeing any user code triggering this provider to be queried

I find this output extremely weird and confusing
```0 problems were found storing the configuration cache.

See the complete report at file:///...../build/reports/configuration-cache/8jv613vpgs12l1jt7kvolgyak/c5cqx0h8dlcjykb6opxpucv6s/configuration-cache-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':app:resignDebug'.
&gt; Failed to query the value of task ':app:resignDebug' property 'packageFile'.
   &gt; java.lang.NullPointerException (no error message)```
I feel like those two things (0 problems + failure) are contradicting each other

I'm not sure how readable this is, but this is a diff of two stacktraces. The one on the left is the provider queried during configuration time. The one on the right is when it is queried during execution time. This is the only section where they differ.

Huh. I've seen the 'failed to unpack provider' thing a few times when task dependencies have accidentally been removed (e.g. `taskProvider.map { it.someProperty.get() }` instead of `taskProvider.flatMap { it.someProperty }`), but beyond that I'm out of my depth. :stuck_out_tongue:

appreciate it nonetheless :slightly_smiling_face: (and that makes two of us)

<https://docs.gradle.org/nightly/userguide/configuration_cache.html#config_cache:not_yet_implemented:fine_grained_tracking_of_gradle_properties>

TL;DR Currently, all external sources of Gradle properties (gradle.properties in project directories and in the GRADLE_USER_HOME, environment variables and system properties that set properties, and properties specified with command-line flags) are considered build configuration inputs regardless of what properties are actually used at configuration time.

<@URQ797WRW> a build scan does not tell us what changed in order to trigger config cache to be considered invalid.

<@UABCKNV3K> Is there a way to get those printed out? The `gradle.properties` and environment variables I can check, as well as command-line flags, but is there a way to print out all properties other than those, that might affect configuration cache? The output of `./gradlew properties` between runs differs in some hashes, could that be the cause? If so, what could be the reason for that, since gradle user home is saved and restored, as well as `&lt;project&gt;/.gradle/configuration-cache`?

Then store the configuration cache report in `build/reports` as artifact, there all inputs should be listed. Then you should be able to compare it or see which might change.

I already do, I get no useful information from that. As far as I understand, that is a report of storing the configuration cache, not using it. Also, from the docs: `These sources, however, are not included in the configuration cache report.`

&gt; As far as I understand, that is a report of storing the configuration cache, not using it.
That's right, but if it does not reuse it for some reason and then stores another one, you should be able to compare the old one with the new one and see a difference.
If there is no difference, it is probably in those mentioned cases that are not added to the report.
So I guess indeed
&gt; The output of `./gradlew properties` between runs differs in some hashes, could that be the cause
is the cause if they come from one of the non-reported locations.
But probably hard to guess without telling which hashes you mean.

property values aren't shown in reports on purpose

<@U03984F25C7> could you please clarify what are those hashes you mention?

gradle_acsd_properties1.txt

gradle_acsd_properties2.txt

So, these are outputs from two runs from `./gradlew properties`  -&gt; if you do a compare you’ll see the differences. They are for instance the `@hash` for these two lines:
```ant: org.gradle.api.internal.project.DefaultAntBuilder@7ffd3d78
antBuilderFactory: org.gradle.api.internal.project.DefaultAntBuilderFactory@6c95d08f ```
I’ve checked, some environment variables also change on CI runs (github actions sets the run id, commit hash, etc. into env), but they aren’t mentioned in the config cache report.

Ok, those aren't part of what the configuration cache looks at.
The `:properties` task uses `Project.getProperties()` which include way too much things.

The question is whether it should contain the "problematic" things.

Yeah, I thought so too, that’s why I’ve been asking if there’s a way to print out the properties config cache is sensitive to, to figure out what is changing :slightly_smiling_face:

Besides the memory addresses of those objects the properties in those files are identical

Here's a task that uses internals to print only what CC considers:
```abstract class ReportLoadedGradleProperties : DefaultTask() {
    @TaskAction
    fun action() {
        println(
            services.get(org.gradle.initialization.GradlePropertiesController::class.java)
                .gradleProperties
                .mergeProperties(emptyMap())
                .entries
                .joinToString("\n")
        )
    }
}

tasks.register&lt;ReportLoadedGradleProperties&gt;("reportLoadedGradleProperties")```

Excellent, thank you for your help. I think I’ve found the culprit: one of the properties is the `secrets.GITHUB_TOKEN`, which we need to authenticate to our internal maven repository. I guess there’s no way around not triggering CC since this is automatically generated by github for each run separately?
Edit: to be clear, we set it with `-PmavenPassword` and retrieve with
```credentials(PasswordCredentials::class)```


You could probably create a fixed token that you supply instead of using the auto-generated one.

Or you just don't care about configuration cache on CI where it shouldn't be *that* relevant :slightly_smiling_face:

Yeah, we might add a static user+password, now that I know what the issue is, although I doubt it, as there’ different permissions for different users. In any case, with this knowledge I can take appropriate actions. CC is not *that* relevant on CI, that’s true, but for some builds it takes longer to configure than to execute the build/test as it’s a big multi module project. Thank you both for all your help getting to the bottom of this :thumbsup:

I have to use that `BuiltArtifactsLoader` to load the file because it knows which file in the Directory I want, and it's how AGP API is designed to be used.

The `testApkDir` doesn't exist until other tasks are executed ( in this case `packageDebugAndroidTest`)

As I'm using "--configuration-cache-problems=warn" the --dry-run is successful

removing that flag, ouch:
&gt; Cannot convert path to File. path='() -&gt; kotlin.String?'
&gt; java.lang.NullPointerException (no error message)
&gt; Cannot convert path to File. path='() -&gt; kotlin.String?'
&gt; java.lang.NullPointerException (no error message)

problems=warn is bad for debugging problems

Seems like some kotlin function is problematic

in any case...
I changed some `file { builtArtifactsLoader.load(apk)?.elements?.single()?.outputFile }`
to: `file(builtArtifactsLoader.load(apk)!!.elements.single().outputFile)`

and now it's only: `java.lang.NullPointerException (no error message)`

So  it seems like something it's called too early, I would say it changes when CC is enabled

that `testApk` is a @InputFile @Classpath so I can understand it's needed

(I have another test that verifies the task is cacheable without CC and works fine)

Let me share another simpler case:
```appApk.set { copySmallApp.destinationDir.listFiles()!!.single() }```
and the error:
```Configuration cache state could not be cached: field '__appApk__' from type 'FlankYmlWriterTask': error writing value of type 'org.gradle.api.internal.file.DefaultFilePropertyFactory$DefaultRegularFileVar'
&gt; copySmallApp.destinationDir.listFiles() must not be null```

(in this case I have a `dependsOn(copySmallApp)`)

But the last example with a Copy task should be easier to reason about, even if it's a different error, it seems the same reason, early evaluation

You should start from a TaskProvider for copySmallApp instead

Plain providers are realized when storing cc, wiring providers all the way is the way to go

Then for the Android case I don't have an option

Because ? Sorry but I'm on the go and can't really browse the related code to understand it all

I don't have the TaskProvider, AGP gives me a Property&lt;Directory&gt; and a class that can extract a File from it

I can wait until tomorrow if you need ( or even make the repo public, but it's not so small)

Assuming the Property&lt;Directory&gt; provided by AGP has proper task dependency information then you should .map{} it

And I do, but you can see in the first message how it doesn't work...

```testApk.value(testApkDir.map {
  it.file(builtArtifactsLoader.load(it)!!.elements.single().outputFile)
})```

Isn't it the `load(it).elements.single` call that is too eager?
What's the type of elements?

I'm now with the kid...
But yes, I expected the load to be executed later, buildArtifactsLoader expects to be execute after the testApkDir provider task

They suggested (in their samples) to give both the Provider&lt;Directory&gt; and the BuildArtifactsLoader to the task, and call the load in the task execution, but then I can't use the APK as a Classpath...well I guess I can use the Provider&lt;Directory&gt; but then id there is any change in the metadata the buildcache would by invalidated...

If I try to annotate as InputFile a method that gets the APK I will have the same issue

I guess I could ignore the BuildArtifactsLoader..and simply filter in Provider&lt;Directory&gt; for any file with APK extension...

Is the metadata changing that much to make the lack of input precision a problem?

No idea, i don't think it's even documented

In general I'd say that a good move would be that AGP provides a proper output for just the APK if it's a common use case

You could report your use case to the Android folks

In the meantime their recommendation sounds reasonable to me

I'll try, thanks

But.. didn't you say a Provider is always executes early unless is a TaskProvider?

I meant "a provider with no task dependencies attached"

One example is using `providers.provider {}`

In case you wonder...everything fixed..

For Copy task... I have created MyCopyTask, using `FileSystemOperations` and declaring an output (`@OutputFile Provider&lt;RegularFile&gt;`)
I don't love it because copy is always a directory (with type `File`.. I guess if it was a `Property&lt;Directory&gt;` I wouldn't need to create my task

For the `apk` file..I'm using the `Provider&lt;Directory&gt;`and also it seems the BuildCache works fine (I wonder if it's relocatable, but I still have to try it)

and about the apk directory: <https://gradle-community.slack.com/archives/CJYS1DAP5/p1650664013906959?thread_ts=1650663746.126369&amp;cid=CJYS1DAP5>

Cheating: obviously you wouldn't be asking if it didn't change when CC is enabled

Random should mean it's "never" up-to-date, but CC .. makes it to be up-to-date always?

So, maybe the CC doesn't understand Random is a "changing input"

Maybe it's worth opening an issue about it

already done <https://github.com/gradle/gradle/issues/20538>

Yeah, memoization like Haskell at it's best

I don’t think this is a bug. It’s expected with the CC. You somehow need to tell Gradle that a value is computed if you grab it from somewhere “outside” of Gradle’s domain/scope. And `Random.Default.nextInt()` is a ‘computation’ Gradle does not know anything about.

~I assume this fixes it?~

Jendrik, if not a bug, at least a very unintuitive side effect, and very likely to produce a lot of bug on third party plugins.

Definitely! Just wanted to point this out from a CC implementation perspective.

I know it’s very difficult to deal with from the usability perspective. In particular for existing builds and plugins which did not follow these new paradigms. One of the reasons why getting the CC to a stable feature already takes so long and will probably still take much longer.
Gradle should probably give an error if it can. But I am not sure if all these things can be detected (in a cheap way).

&gt; and will probably still take much longer
not that we can't use it, but.. :cry:

As Jendrik wrote, this is expected. For changing values you should implement a `ValueSource` <https://docs.gradle.org/current/javadoc/org/gradle/api/provider/ValueSource.html>

The _code_ will be captured by CC and the value obtained on each build invocation including when loading the configuration cache.

I agree, but I brought it up because my initial reaction was "wow! that's not intuitive at all." And then I became afraid for the world of community plugin authors

if anything, this really shows the value of testing one's plugins. but a plugin author has no control over the context in which their plugin is applied. and creating test fixtures should be easier

Related <https://github.com/gradle/gradle/issues/20538>

This works starting with the upcoming Gradle 7.5
<https://docs.gradle.org/release-nightly/userguide/configuration_cache.html#config_cache:requirements:external_processes>

Awesome, thank you! And this answered my next question:
&gt; The external process will be executed for every build to determine if the configuration cache is up-to-date, so it is recommended to only call fast-running processes at configuration time.

If after tasks is good too, yes. For before I think no

problem I need to copy files before another task is running

```target.gradle.taskGraph.beforeTask { task -&gt;
    if (task.name == "some name") {
        // add files to build/some-dir
    }
}```

Sounds like you definitely should not do that anyway

But other than that, you could just register a `doFirst` action with the task in question

This should be the same then?

```val task =
    target.tasks.named("some name").apply {
        configure {
            it.doFirst {
                // add files to build/some-dir
            }
        }
    }```


```DefaultTaskContainer#NamedDomainObjectProvider.configure(Action) on task set cannot be executed in the current context.```

So, you can configure another task, but you can't do it, for example, from another task

Yeah, the problem this was a mess, I am refactoring instead of trying to get it working because it is awful to maintain at this moment

&gt; So, you can configure another task, but you can't do it, for example, from another task
Of course you can, as long as you don't need configuration cache compatibility.
But most often there are better ways.

Sorry for the confusion. The milestone doesn't have Adam's latest changes in it. We changed a lot of things in the promotion build and used the milestone to check for problems.

Did you try to reproduce this with a nightly?

RC1 is coming out today, so if you could give that a try, it would be much appreciated

Hi Tony,

For reference <https://docs.gradle.org/7.5-rc-1/userguide/configuration_cache.html#config_cache:stable>

I'll reply about what the feature flag currently covers.

&gt; What would happen if I enabled that flag on a build that didn't have CC on?
Undeclared build service usages will emit a deprecation warning as they are not tied to CC being enabled.
You could argue that this could have been put behing yet another feature flag.

Undeclared external processes used at configuration time won't be affected because there's no point.

&gt; On a build that did have it on?
Same for undeclared build services.

Undeclared external processes used at configuration time will emit a problem.

&gt; If I run a task that isn't compatible with CC in either of those scenarios?
It's basically the same. But undeclared external processes used at configuration time don't apply because `Task.notCompatibleWithConfigurationCache()` is about task execution problems.

HTH

I might remember wrongly, but I mean to remember that this is *not* a new issue but expected behavior, even if unintuitive.

Is there anyway to override `org.gradle.unsafe.configuration-cache-problems` in the project if the `~/.gradle/gradle.properties` has it set?  setting it to empty doesn't have an effect, and it still fails.

Yeah, I remembered correctly.
This is the thread I had in mind: <https://gradle-community.slack.com/archives/C013WEPGQF9/p1642504611003200>
And here the original issue to your duplicate: <https://github.com/gradle/gradle/issues/19622>
In both Gradle guys say this is by design, because the property says that all problems are treated as warning everywhere and it should just continue.

And no, I think if you set it in `~/.gradle/gradle.properties` you can only detect it and fail the build.
You can only override it via command-line in that case iirc.

if that's expected behavior, I think it's the wrong expectation

hmm but I kinda get why it would be so :thinking_face:

Gradle should probably improve the error message to make this more clear

Don't tell me, I also thought it is a bug until several Gradle guys said this is by design and expected

basically the combination of `notCompatible...` + that warning is clearly incompatible. That itself ought to be considered a kind of error

They at least wanted to improve the described implications of the flag in the docs, not sure whether they did already.

Thanks for your quick replies <@URQ797WRW>.  That helps provide context.  Hopefully we can get someone from their team to link to an issue/documentation/something calling this behavior out.

Here is the issue they have open to address it: <https://github.com/gradle/gradle/issues/20673>

And here the documentation with the explicit description: <https://docs.gradle.org/7.4.2/javadoc/org/gradle/api/Task.html#notCompatibleWithConfigurationCache-java.lang.String->
&gt; The presence of incompatible tasks in the task graph will cause the configuration state to be discarded at the end of the build unless the global `configuration-cache-problems` option is set to `warn`, in which case the configuration state would still be cached in a best-effort manner as usual for the option.


And if you want to interpret the other docs in the Gradle way, the `notCompatibleWithConfigurationCache()` descriptions says
&gt; Configuration cache problems found in tasks marked incompatible will no longer cause the build to fail.
And the description of `org.gradle.unsafe.configuration-cache-problems=warn` says
&gt; turn problems into warnings
So with the flag, there are no problems anymore and thus the method has no effect anymore.

this is an issue in 7.4. Fixed in 7.5-rc-1

Try with configuration cache disabled, it's perhaps caching the vpn status.

If that is the case the provider invocation can be moved into the buildcache block

Hi Gianfranco,
Given this changes the configuration of your build you'll want to run this function on each build invocation and invalidate the configuration cache when its return value change. In order to do this you need to implement a `ValueSource` and use it via `ProviderFactory.of(...)`.
See <https://docs.gradle.org/current/javadoc/org/gradle/api/provider/ValueSource.html>

Hi <@UABCKNV3K>. So I ended up with this:
```interface VpnParameters extends ValueSourceParameters {
    Property&lt;String&gt; getServerUrl();
}

abstract class VpnConnectionSource implements ValueSource&lt;Boolean, VpnParameters&gt; {
    @Override
    Boolean obtain() {
        String serverUrl = getParameters().serverUrl.get()
        return hasServerConnection(serverUrl)
    }

    boolean hasServerConnection(String serverUrl) {
        try (Socket socket = new Socket()) {
            // Logic to check if we have a connection to our VPN
            println "Found VPN connection for $serverUrl"
            return true
        } catch (Exception exception) {
            println "VPN connection not found for $serverUrl (Reason: '${exception.message}')."
            return false
        }
    }
}

String url = "<https://my.vpn.com>"
def vpnProvider = settings.providers.of(VpnConnectionSource.class) {
    parameters {
        serverUrl = url
    }
}

println(vpnProvider.get().class)
boolean remoteCacheEnabled = vpnProvider.get()
println "Remote cache enabled: $remoteCacheEnabled"

buildCache {
    remote(HttpBuildCache) {
        enabled = remoteCacheEnabled
        push = isCi
        url = "$url/cache/"
    }
}```
However, when I run `./gradlew :app:assembleDebug` , I'm encountering this error:
```Found VPN connection for <https://my.vpn.com>
class java.lang.Boolean
Remote cache enabled: true
FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Could not create service of type BuildCacheController using .createBuildCacheController().
   &gt; HTTP build cache has no URL configured```
This error is the same as this one from <https://github.com/gradle/gradle/issues/14874>. Is this fixed in Gradle 7.5?

This issue is about a custom build cache implementation, that's a different thing.

`HTTP build cache has no URL configured` would seem to indicate that the URL is not being correctly set

`HTTP build cache has no URL configured` looks weird to me given you have
```url = "$url/cache/"```
Are you sure this is a valid URL to a build cache node?

If I change it to this, then it works and I can accesss the remote cache.
```buildCache {
    remote(HttpBuildCache) {
        enabled = true // Dont use the provider
        push = isCi
        url = "$url/cache/"
    }
}```
```Found VPN connection for <https://my.vpn.com>
class java.lang.Boolean
Remote cache enabled: true

BUILD SUCCESSFUL in 54s
9280 actionable tasks: 129 executed, 336 from cache, 8815 up-to-date```

It seems like the error is only happening when I use the result of `provider.get()` in `buildCache`

Could you please try moving the creation of the value source inside the `remote(HttpBuildCache) {}` lambda? It's just to rule out something

Like that:
```buildCache {
    def providers = settings.providers
    remote(HttpBuildCache) {

        String url = "<https://my.vpn.com>"
        def vpnProvider = providers.of(VpnConnectionSource.class) {
            parameters {
                serverUrl = url
            }
        }

        println(vpnProvider.get().class)
        boolean remoteCacheEnabled = vpnProvider.get()
        println "Remote cache enabled: $remoteCacheEnabled"

    
        enabled = remoteCacheEnabled
        push = isCi
        url = "$url/cache/"
    }
}```

Same error

```Found VPN connection for <https://my-vpn.com>
class java.lang.Boolean
Remote cache enabled: true

FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Could not create service of type BuildCacheController using .createBuildCacheController().
   &gt; HTTP build cache has no URL configured```

I need to run now. Something is not right. Please open an issue with this reproducer and the team can look at it

Quick question: you get that error on the first build, calculating the task graph? or only on the second build, reusing the configuration cache?

It's happening with both the configuration-cache enabled and disabled.

It's also happening on Gradle 7.5, I'm going to open an issue. Thanks for the support.

Oh wait, I just realized that with your code above it works if the provider's value does not change.

```buildCache {
    def providers = settings.providers
    remote(HttpBuildCache) {

        String url = "<https://my.vpn.com>"
        def vpnProvider = providers.of(VpnConnectionSource.class) {
            parameters {
                serverUrl = url
            }
        }

        println(vpnProvider.get().class)
        boolean remoteCacheEnabled = vpnProvider.get()
        println "Remote cache enabled: $remoteCacheEnabled"

    
        enabled = remoteCacheEnabled
        push = isCi
        url = "$url/cache/"
    }```
I guess there must be a reasonable explanation for that behavior :sweat_smile:

First build with `./gradlew :app:assembleDebug` and no VPN connection
```Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Calculating task graph as configuration cache cannot be reused because file 'tools/gradle-cache-node-config.gradle' has changed.
VPN connection not found for <https://my.vpn.com> (Reason: 'Connect timed out').
Remote cache enabled: false

BUILD SUCCESSFUL in 1m 4s
9280 actionable tasks: 9280 up-to-date
Configuration cache entry stored.```
Second build with `./gradlew :app:assembleDebug` and no VPN connection:
```Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
VPN connection not found for <https://my.vpn.com> (Reason: 'Connect timed out').
Reusing configuration cache.

BUILD SUCCESSFUL in 5s
9275 actionable tasks: 9275 up-to-date
Configuration cache entry reused.```
Third build with `./gradlew :app:assembleDebug` and connected to the VPN; however, it fails with the same error than before
```Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Found VPN connection for <https://my.vpn.com>
Calculating task graph as configuration cache cannot be reused because a build logic input of type 'VpnConnectionSource' has changed.
Found VPN connection for <https://my.vpn.com>
Remote cache enabled: true

0 problems were found storing the configuration cache.

See the complete report at file:///Users/gianfranco.monzon/Documents/rappi/build/reports/configuration-cache/a4ykle2laqrcw1011gdh200a0/bkc4qjoucgl778cxj19sj43su/configuration-cache-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Could not create service of type BuildCacheController using .createBuildCacheController().
   &gt; HTTP build cache has no URL configured```

try without configuration on demand, that seems to be a very experimental / problematic feature.

Same error without configuration on demand. This is my `gradle.properties`
```# Project-wide Gradle settings
org.gradle.daemon=true
org.gradle.parallel=true
# org.gradle.configureondemand=true
org.gradle.caching=true
org.gradle.jvmargs=-Dfile.encoding=UTF-8 -Xmx8g -Xms4g -XX:+UseParallelGC
org.gradle.unsafe.configuration-cache=true

kotlin.incremental.usePreciseJavaTracking=true
kapt.include.compile.classpath=false
kapt.incremental.apt=true

android.useAndroidX=true
android.enableJetifier=true
android.databinding.incremental=true
android.experimental.cacheCompileLibResources=true
android.experimental.enableSourceSetPathsMap=true

rappi.localBuild=true
rappi.payMocksEnabled=true ```

Did this message go away: `Configuration on demand is an incubating feature.`

Yes
```Configuration cache is an incubating feature.
Calculating task graph as configuration cache cannot be reused because file 'gradle.properties' has changed.
VPN connection not found for <https://my.vpn.com> (Reason: 'Connect timed out').
Remote cache enabled: false

BUILD SUCCESSFUL in 34s
9280 actionable tasks: 3 from cache, 9277 up-to-date
Configuration cache entry stored.```
```Configuration cache is an incubating feature.
VPN connection not found for <https://my.vpn.com> (Reason: 'Connect timed out').
Reusing configuration cache.

BUILD SUCCESSFUL in 4s
9275 actionable tasks: 3 from cache, 9272 up-to-date
Configuration cache entry reused.```
```Configuration cache is an incubating feature.
Found VPN connection for <https://my.vpn.com>
Calculating task graph as configuration cache cannot be reused because a build logic input of type 'VpnConnectionSource' has changed.
Found VPN connection for <https://my.vpn.com>
Remote cache enabled: true

0 problems were found storing the configuration cache.

See the complete report at file:///Users/gianfranco.monzon/Documents/rappi/build/reports/configuration-cache/a4ykle2laqrcw1011gdh200a0/bkc4qjoucgl778cxj19sj43su/configuration-cache-report.html

FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Could not create service of type BuildCacheController using .createBuildCacheController().
   &gt; HTTP build cache has no URL configured```

Interesting enough, if I mark eveyrthing as final, then the problem goes away. :thinking_face:

```final String nodeUrl = "<https://gradle-cache.dev.rappi.com>"

final def vpnProvider = settings.providers.of(VpnConnectionSource.class) {
    parameters {
        serverUrl = nodeUrl
    }
}

final boolean remoteCacheEnabled = vpnProvider.get()
println "Remote cache enabled: $remoteCacheEnabled"

buildCache {
    remote(HttpBuildCache) {
        enabled = remoteCacheEnabled
        push = isCi
        url = "$nodeUrl/cache/"
    }
}```

First build without VPN
```./gradlew :app:assembleDebug
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Calculating task graph as configuration cache cannot be reused because file 'tools/ge/gradle-cache-node-config.gradle' has changed.
VPN connection not found for <https://gradle-cache.dev.rappi.com> (Reason: 'Connect timed out').
Remote cache enabled: false

0 problems were found storing the configuration cache.

See the complete report at file:///Users/gianfranco.monzon/Documents/rappi/build/reports/configuration-cache/a4ykle2laqrcw1011gdh200a0/cxkjktsjf93db8q40gs6s3tn9/configuration-cache-report.html

BUILD SUCCESSFUL in 1m 1s
9280 actionable tasks: 9280 up-to-date
Configuration cache entry stored.```
Second build without VPN
```./gradlew :app:assembleDebug
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
VPN connection not found for <https://gradle-cache.dev.rappi.com> (Reason: 'Connect timed out').
Reusing configuration cache.

BUILD SUCCESSFUL in 7s
9275 actionable tasks: 3 from cache, 9272 up-to-date
Configuration cache entry reused.```
Third build with VPN
```./gradlew :app:assembleDebug
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Found VPN connection for <https://gradle-cache.dev.rappi.com>
Calculating task graph as configuration cache cannot be reused because a build logic input of type 'VpnConnectionSource' has changed.
Found VPN connection for <https://gradle-cache.dev.rappi.com>
Remote cache enabled: true

0 problems were found storing the configuration cache.

See the complete report at file:///Users/gianfranco.monzon/Documents/rappi/build/reports/configuration-cache/a4ykle2laqrcw1011gdh200a0/6vueooe9ptz278qk8ui6l7my6/configuration-cache-report.html

BUILD SUCCESSFUL in 27s
9280 actionable tasks: 3 from cache, 9277 up-to-date
Configuration cache entry stored.```
Fourth build with VPN (this one went really slow compared to the second build)
``` ./gradlew :app:assembleDebug
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Found VPN connection for <https://gradle-cache.dev.rappi.com>
Reusing configuration cache.

BUILD SUCCESSFUL in 49s
9275 actionable tasks: 3 from cache, 9272 up-to-date
Configuration cache entry reused.```
Fifth build without VPN to test if everything keeps working and I got this error
```Starting a Gradle Daemon, 1 busy and 4 stopped Daemons could not be reused, use --status for details
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Gradle could not start your build.
&gt; Cannot create service of type BuildTreeActionExecutor using method LauncherServices$ToolingBuildTreeScopeServices.createActionExecutor() as there is a problem with parameter #1 of type List&lt;BuildActionRunner&gt;.
   &gt; Cannot create service of type BuildModelActionRunner using BuildModelActionRunner constructor as there is a problem with parameter #1 of type PayloadSerializer.
      &gt; Cannot create service of type PayloadSerializer using method LauncherServices$ToolingGradleUserHomeScopeServices.createPayloadSerializer() as there is a problem with parameter #2 of type PayloadClassLoaderFactory.
         &gt; Cannot create service of type PayloadClassLoaderFactory using method LauncherServices$ToolingGradleUserHomeScopeServices.createClassLoaderFactory() as there is a problem with parameter #1 of type CachedClasspathTransformer.
            &gt; Cannot create service of type DefaultCachedClasspathTransformer using DefaultCachedClasspathTransformer constructor as there is a problem with parameter #6 of type FileSystemAccess.
               &gt; Cannot create service of type FileSystemAccess using method VirtualFileSystemServices$GradleUserHomeServices.createFileSystemAccess() as there is a problem with parameter #2 of type VirtualFileSystem.
                  &gt; Cannot create service of type BuildLifecycleAwareVirtualFileSystem using method VirtualFileSystemServices$GradleUserHomeServices.createVirtualFileSystem() as there is a problem with parameter #6 of type GlobalCacheLocations.
                     &gt; Cannot create service of type GlobalCacheLocations using method GradleUserHomeScopeServices.createGlobalCacheLocations() as there is a problem with parameter #1 of type List&lt;GlobalCache&gt;.
                        &gt; Could not create service of type FileAccessTimeJournal using GradleUserHomeScopeServices.createFileAccessTimeJournal().
                           &gt; Timeout waiting to lock journal cache (/Users/gianfranco.monzon/.gradle/caches/journal-1). It is currently in use by another Gradle instance.
                             Owner PID: 36627
                             Our PID: 37151
                             Owner Operation: 
                             Our operation: 
                             Lock file: /Users/gianfranco.monzon/.gradle/caches/journal-1/journal-1.lock```
Sixth build without VPN to test if everything keeps working.
```./gradlew :app:assembleDebug
Starting a Gradle Daemon, 5 stopped Daemons could not be reused, use --status for details
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
VPN connection not found for <https://gradle-cache.dev.rappi.com> (Reason: 'Connect timed out').
Calculating task graph as configuration cache cannot be reused because a build logic input of type 'VpnConnectionSource' has changed.
VPN connection not found for <https://gradle-cache.dev.rappi.com> (Reason: 'Connect timed out').
Remote cache enabled: false

0 problems were found storing the configuration cache.

See the complete report at file:///Users/gianfranco.monzon/Documents/rappi/build/reports/configuration-cache/a4ykle2laqrcw1011gdh200a0/xj79okyqfag8uftok0ng1ih3/configuration-cache-report.html

BUILD SUCCESSFUL in 50s
9280 actionable tasks: 3 from cache, 9277 up-to-date
Configuration cache entry stored.```
Build is successful, but it did not reuse the configuration cache from the first build when it should have been reused. Is this expected behavior?

I think <https://github.com/gradle/gradle/issues/20126> could explain why some CC problems were not reported

&gt; Build is successful, but it did not reuse the configuration cache from the first build when it should have been reused. Is this expected behavior?
Unfortunately yes, the cache key would be the same but the cache fingerprint invalidates it. That's an interesting case for which the current scheme is counter productive.