New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building gradle itself fails during toolchain download: permission denied copying a file within .gradle/jdks
#22796
Comments
I am encountering a similar issue in one of my projects. Although my project workflow is using JDK 19 instead of JDK 11. See |
If another data point helps, we're seeing what I think is the same issue in the Micrometer build (see, for example, https://ge.micrometer.io/s/vxhaweu5wfjhm) which we're tracking with micrometer-metrics/micrometer#3549. |
I also see this on my own project with Adoptium 16.0.2+7 and 17.0.5+8 on Linux. Gradle 7.6 successfully downloads the JDK, but encounters a |
Thank you all for the information and reproducers. We now understand what is causing the problems and are working on a fix. |
Gradle 7.6 causes the CI to fail because of gradle/gradle#22796. This reverts commit 4d00b4e.
This should effectively get rid of gradle/gradle#22796 for now
gradle/gradle#22796 happens on CI. Maybe this will fix it
Previous version had issues with java toolchain download. gradle/gradle#22796
Expected Behavior
Able to build Gradle
Current Behavior
Building Gradle fails as of roughly September 30th if a JDK11 toolchain needs to be downloaded, failing during unpacking the downloaded JDK with a permission error while copying
.gradle/jdks/OpenJDK11U-jdk_x64_mac_hotspot_11/...some-read-only-file
to.gradle/jdks/eclipse_adoptium-11-x86_64-os_x/...some-read-only-file
Build works as expected if the needed JDK is found through detection on your local system, or was in
.gradle/jdks
already, including because of a previous failure building this project.Context
Steps to Reproduce
git clone https://github.com/gradle/gradle; cd gradle; git checkout 4595851c30a4dc95a68c460e9b95259ca60b8060
(currentmaster
as of time of writing)$HOME/.gradle/jdks
to ensure the build will try to download a toolchain./gradlew -Dorg.gradle.java.home=/some/jdk11/home/ -Porg.gradle.java.installations.auto-detect=false
(using auto-detect=false to ensure a local JDK isn't picked up)Result:
The specific file varies, and can be any file in the JDK tarball with a read-only mode, e.g. the LICENSE or README files, or various
.md
files in the legal subdirectory. The failure results because we're trying to truncate and overwrite a read-only file. Given the simplicity ofprovisionFromArchive
(https://github.com/gradle/gradle/blob/master/subprojects/platform-jvm/src/main/java/org/gradle/jvm/toolchain/internal/install/JdkCacheDirectory.java#L120), I suspect this is a case of mistakenly calling that routine twice without cleaning up the install directory, so the first unpack goes as expected, then the second tries to overwrite the first and fails due to these read-only files.I first noticed this because lgtm.com started failing to build
gradle/gradle
on September 30th; the times of its regular builds allow us to isolate the problem to this commit range: 764ed77...5eb9596Your Environment
This is reproducible on many platforms: lgtm.com's workers as mentioned above are based on Ubuntu 20.04, but I can also reproduce the problem on MacOS Ventura with the same symptoms. Reproducibility can vary based on the JDKs available locally, but clearing
.gradle/jdks
and using-Porg.gradle.java.installations.auto-detect=false
to insist on a downloaded toolchain seems to reliably reproduce the problem.The text was updated successfully, but these errors were encountered: