This message was deleted.
# configuration-cache
s
This message was deleted.
t
it's not immediately clear to me why the CC would be discarded. This is a task input that is evaluated at execution time
j
I am not talking about a task input, it is a property in my extension
v
Why should the configuration cache be discarded? Just having input files changed should not discard the configuration cache. If you change a source file and rerun the build, the configuration cache should of course be reused and just the changed file recompiled, even if the input file would be on a task.
j
Then how can I force the configuration cache to be discarded when that file tree has changed?
t
why do you want it to be?
j
the project version is changed based on multiple states, so if the repo is clean, and after that, the repo is no longer clean, the version should be changing, but configuration cache is blocking that change
or, for example, the project version uses the last commit hash, if a new commit appears, the project version has to have that new commit hash, the configuration cache is blocking this change too
v
ValueSource
?
providers.fileContents(...).asBytes.get()
? If you look at the CC HTML report the files must be listed as inputs. If they are not listed as inputs, changing them will not invalidate the CC.
j
Looks like my value source is not changing the version with configuration cache
v
Well, maybe your value source is wrong then? 🙂 value source is always recalculated whether CC entry is reused or not. If CC entry is reused and the value source returns a different result, CC entry is discarded and configuration is done, including evaluating your value source a second time.
j
that is the weird thing, all tests are passing doing similar things, but with configuration cache, it isn't
v
🤷‍♂️
j
Copy code
val files: List<File> =
    project.file("${rootProject.rootDir}/.git").walkTopDown().toList()
it.parameters.gitDir.from(files)
Is it not only necessary to set the git dir to the parameters, it has to be used in order to take it in account to discard the configuration cache?
v
Your file listing is done at configuration time. So it cannot invalidate the configuration cache.
j
I don't understand how ValueSource works, the same input has to be passed to a task?
v
What do you not understand?
j
How can I invalidate it based on any change of those files
v
If the value of the value source changes, the CC is discarded
j
So, if the value source is changing without the configuration cache with no issues, but it is not changing with configuration cache, that means I am depending entirely on configuration to indicate the value source that has to be changed, is this an chicken egg issue?
by creating a different jgit instance inside of the value source and using it to check if it is clean it is fixed, I would prefer passing the original one, but I think it is not possible due it is not serializable