Resolution fails with: Could not update timestamp for ... descriptor.bin.fslck caused by NoSuchFileException #11752
Comments
vlsi
added a commit
to autostyle/autostyle
that referenced
this issue
Dec 27, 2019
Try as a workaround for gradle/gradle#11752
vlsi
added a commit
to autostyle/autostyle
that referenced
this issue
Dec 27, 2019
Try as a workaround for gradle/gradle#11752
vlsi
added a commit
to autostyle/autostyle
that referenced
this issue
Dec 27, 2019
Try as a workaround for gradle/gradle#11752
nedtwigg
added a commit
to diffplug/spotless
that referenced
this issue
Dec 30, 2019
…everting to 5.5.1 until gradle/gradle#11752 gets resolved.
|
An interesting note is that it seems to be caused only when the detached configuration is using |
|
Just had my first failure on a resolve from |
|
This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution. |
|
This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request. |
|
I just came across what seems to be the same issue, in Gradle 7.1. This happened in a test scenario where multiple parallel GradleRunners were executing. The GradleRunners ran Gradle 6.2.2 so I suppose legacy code is executing here. |
|
@ov7a can you please reopen this one? |
|
Urgh, sorry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
Resolution for detached configurations should not fail provided all the artifacts exist.
Current Behavior
Sometimes Gradle fails. The failure is observable on both GitHub Actions Linux and Travis Linux.
Sample failure: https://github.com/autostyle/autostyle/commit/54edfa37955c3c8b13ac5572809f80cf60f46c7a/checks?check_suite_id=371157890#step:4:795
Travis failure: https://travis-ci.org/autostyle/autostyle/jobs/628610212#L431
Bot jobs have
--stacktrace, but GitHub Actions has more stacktraces while Travs has justcaused by..caused by.Relevant stack:
AFAIK, the code in question is https://github.com/gradle/gradle/blame/4b850efa1544ad0e14ac45d56059ec3a3d7f4a90/subprojects/core/src/main/java/org/gradle/internal/resource/local/DefaultPathKeyFileStore.java#L142
My understanding is that concurrent
deleteFileQuietlyoperation (see https://github.com/gradle/gradle/blame/4b850efa1544ad0e14ac45d56059ec3a3d7f4a90/subprojects/core/src/main/java/org/gradle/internal/resource/local/DefaultPathKeyFileStore.java#L151 ) deletes the file exactly in-between of lines 58-59 (see https://github.com/gradle/gradle/blame/80d23c35a059d3eb63f71b4504d0755e1ee09c65/subprojects/base-services/src/main/java/org/gradle/util/GFileUtils.java#L58-L59 )In other words:
It is surprising that the relevant code was like that for ages, however, the above sequence looks quite plausible to me.
@lptr , @adammurdoch what do you think?
Context
It fails my Travis / GitHubActions builds 42% of the time (I don't know the percentage, but it is really often)
The resolution code is as follows:
https://github.com/autostyle/autostyle/blob/d6be709181341592bf90376ec6c0b87d1ab84d08/testlib/src/main/kotlin/com/github/autostyle/TestProvisioner.kt#L50-L63
Steps to Reproduce
Restart Travis or GHA job until it fails.
Your Environment
Gradle 6.0.1
Does build scan help?
I can try to make Travis job to produce a build scan, but I would like to refrain spending time on something that won't really help.
The text was updated successfully, but these errors were encountered: