https://gradle.com/ logo
Join SlackCommunities
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
j
Copy code
Output:
Encryption of the configuration cache is enabled.
Calculating task graph as no configuration cache is available for tasks: fooTask

0 problems were found storing the configuration cache.

See the complete report at ...

FAILURE: Build failed with an exception.

* What went wrong:
Failed to create MD5 hash for file content.
> The process cannot access the file because another process has locked a portion of the file
c
that may not be related to encryption. Gradle has always used MD5 hashes for file content. A stacktrace would be helpful for details, though it looks like contention on a file.
j
interesting, with stacktrace looks like my settings plugin which shouldn't be related, is now failing due to these function
Copy code
internal fun Settings.extractedProjects(): Set<String> =
    settingsDir
        .walkTopDown()
        .onEnter { file -> file.shouldContinueVisiting(settings) }
        .flatMap { file ->
            val children = file.listFiles()?.filter { child -> child.isProject }
            children?.map { child -> child.relativeTo(settingsDir).path }.orEmpty()
        }
        .toSet()
This line:
Copy code
val children = file.listFiles()?.filter { child -> child.isProject }
probably caused by 
listFiles()
c
hmmm. would need to look it up - there are som of those file listing/walking/visiting constructs that require closing resources.
j
I am going to move to 
_walkTopDown_().maxDepth(1)
👍 1
v
What is 
isProject
? Does it maybe open the file but not close it?
j
Copy code
private val File.isProject: Boolean
    get() = hasBuildGradle && !isSettingsProject
I am finding all projects or included builds automatically
and those booleans was using 
listFiles()
too, after moving to 
walkTopDown
the issue is gone
I wouldn't expect I need to close any resource manually with 
listFiles
tho
c
correct, 
listFiles
doesn’t need resource cleanup. it was likely related to walking through the entire tree, limiting your search has reduced/removed the contention.
j
but I am finding the same files with both approaches, right?
c
assuming your previous logic stopped at a depth of 1, yes, that would be equivalent to 
_walkTopDown_().maxDepth(1)
j
I moved from
Copy code
internal fun Settings.extractedProjects(): Set<String> =
    settingsDir
        .walkTopDown()
        .onEnter { file -> file.shouldContinueVisiting(settings) }
        .flatMap { file ->
            val children = file.listFiles()?.filter { child -> child.isProject }
            children?.map { child -> child.relativeTo(settingsDir).path }.orEmpty()
        }
        .toSet()
to
Copy code
internal fun Settings.extractedProjects(): Set<String> =
    settingsDir
        .walkTopDown()
        .onEnter { file -> file.shouldContinueVisiting(settings) }
        .flatMap { file ->
            val children = (file.walkTopDown().maxDepth(1) - file).filter { child -> child.isProject }
            children.map { child -> child.relativeTo(settingsDir).path }
        }
        .toSet()
I think both are checking the exactly same files
Open in Slack
PreviousNext
Powered by