Skip to content
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

configuration cache with included build causes --profile unable to create directory #18386

Closed
mathjeff opened this issue Sep 23, 2021 · 11 comments · Fixed by #28512
Closed

configuration cache with included build causes --profile unable to create directory #18386

mathjeff opened this issue Sep 23, 2021 · 11 comments · Fixed by #28512
Assignees
Labels
Milestone

Comments

@mathjeff
Copy link
Contributor

Expected Behavior

If I run a build that uses an included build, has configuration caching enabled, and uses the --profile argument, I'd like the process of generating the profile report to succeed.

Current Behavior

Currently if I do the above, I observe that Gradle says it cannot create the report directory:

Could not stop build 'doclava'.
org.gradle.api.UncheckedIOException: Could not write to file 'reports/profile/profile-1969-12-31-19-00-00.html'.
	at org.gradle.internal.IoActions$TextFileWriterIoAction.execute(IoActions.java:152)
	at org.gradle.internal.IoActions$TextFileWriterIoAction.execute(IoActions.java:127)
	at org.gradle.internal.IoActions.writeTextFile(IoActions.java:45)
...
Caused by: java.io.IOException: Unable to create directory 'reports/profile'
	at org.gradle.internal.IoActions$TextFileWriterIoAction.execute(IoActions.java:142)

Context

This makes it slightly more difficult to enable configuration caching in androidx ( https://android.googlesource.com/platform/frameworks/support/ )

Steps to Reproduce

See https://github.com/mathjeff/gradle-samples/tree/master/included-build-configuration-cache-profile

Your Environment

Build scan URL: https://scans.gradle.com/s/22l2n2jlpv5ac

Note that the failure is in generating the profile report file, which happens after publishing the build scan, and so the build scan might not mention the failure to create the profile report file

@mathjeff
Copy link
Contributor Author

Also interesting, if I run mkdir reports, that seems to cause the build to succeed

@mathjeff
Copy link
Contributor Author

It seems that in this situation, Gradle is trying to put the reports into ./reports whereas it would be nice for them to go into something more like ${rootProject.buildDir}/reports

copybara-service bot pushed a commit to androidx/androidx that referenced this issue Sep 24, 2021
Also adding an exemption for it being in the source dir
Also informing `./gradlew --clean` where to find it

Bug: 180423646
Bug: gradle/gradle#18386

Test: enable configuration caching and run `./busytown/androidx.sh` and see that it no longer fails to create the report directory
Change-Id: Id32c350c3bcb1328669a3c04c2a2d110930627f0
@yigit
Copy link

yigit commented Nov 29, 2021

I'm seeing this same problem in another script where i run the profile multiple times.

I think the real issue in my case is the date 1969-12-31-19-00-00 seems like maybe it is unable to read the date properly? (also, it happens in the second invocation).

A build scan was not published as you have not authenticated with server 'ge.androidx.dev'.
Configuration cache entry stored with 11 problems.
run #1 of 10
Executing ./gradlew --init-script /home/yboyar/src/androidx-main/frameworks/support/room/scripts/rerun-requested-task-init-script.gradle --profile :room:integration-tests:room-testapp-kotlin:kspWithKspDebugAndroidTestKotlin
result: file:///home/yboyar/src/androidx-main/frameworks/support/playground-common/playground-plugin/build/reports/profile/profile-2021-11-29-09-19-22.html file:///home/yboyar/src/androidx-main/frameworks/support/out/room-playground/room-playground/build/reports/profile/profile-2021-11-29-09-19-22.html
total time spent for in this run  file:///home/yboyar/src/androidx-main/frameworks/support/out/room-playground/room-playground/build/reports/profile/profile-2021-11-29-09-19-22.html: 0
run #2 of 10
Executing ./gradlew --init-script /home/yboyar/src/androidx-main/frameworks/support/room/scripts/rerun-requested-task-init-script.gradle --profile :room:integration-tests:room-testapp-kotlin:kspWithKspDebugAndroidTestKotlin
Could not stop build ':'.
org.gradle.api.UncheckedIOException: Could not write to file 'reports/profile/profile-1969-12-31-16-00-00.html'.

@sandipchitale
Copy link

FWIW, in the IntelliJ debugger, I see that the canonical path for 'reports/profile' resolves to '~/.gradle/daemon/7.4.2/reports/profile' and the mkdirs() call below fails with the exception.

                File parentFile = file.getParentFile();
                if (parentFile != null) {
                    if (!parentFile.mkdirs() && !parentFile.isDirectory()) {
                        throw new IOException(String.format("Unable to create directory '%s'", parentFile));
                    }
                }

@RicardoJiang
Copy link
Contributor

same question

@Gozdeee1
Copy link

Same here

@klboke
Copy link

klboke commented Jan 10, 2023

same question +1

@VitalyVPinchuk
Copy link

Hi, same here.
But I created reports/profile manually in the folder where I run ./gradlew from.
So the report was successfully created, though Gradle reported it was created in ~/.gradle/daemon/7.6/reports/profile/profile-1969-12-31-20-00-00.html

Any ideas?

@mlopatkin mlopatkin added in:configuration-cache Configuration Caching and removed to-triage labels Mar 20, 2023
@ov7a ov7a added the in:profile-report BuildProfile --profile label Sep 13, 2023
@jandry
Copy link

jandry commented Sep 25, 2023

Still same issue today using gradle 8.3

@franckrasolo
Copy link

Likewise with Gradle 8.6

@esafirm
Copy link

esafirm commented Mar 6, 2024

With reports directory exist, this error could be avoided, but it seems the report content also not correct.

CleanShot 2024-03-06 at 09 31 15@2x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.