Output of asciidoctorPdf can be pulled from cache when run on machines with different checkout directories
#2794
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This sets the path sensitivity to relative for the sourceDir property of the asciidoctorPdf task. Previously, the full absolute path to the sources directory would be considered as an input to the task. This would cause a local build cache miss when executing the task from two different directories or a remote build cache hit given that the paths to the sources directory on CI and for local developers will undoubtedly be different.
erichaagdev
changed the title
asciidoctorPdf receives a cache hit when run on machines with different checkout pathsasciidoctorPdf can be pulled from cache when run on machines with different checkout directories
erichaagdev
changed the title
asciidoctorPdf can be pulled from cache when run on machines with different checkout directoriesasciidoctorPdf can be pulled from cache when run on machines with different checkout directories
artembilan
reviewed
Sep 1, 2023
| @@ -497,7 +497,7 @@ asciidoctorPdf { | |||
|
|
|||
| asciidoctorj { | |||
| sourceDir "$buildDir/asciidoc" | |||
| inputs.dir(sourceDir) | |||
| inputs.dir(sourceDir).withPathSensitivity(PathSensitivity.RELATIVE) | |||
There was a problem hiding this comment.
I guess something like build/asciidoc would work as well, but then sourceDir property of the asciidoctorj plugin might not be happy.
I'll merge after your answer.
Thanks
There was a problem hiding this comment.
BTW, we are in the process of migrating our docs to Antora, so very likely this PDF generation task will go away, like we have now in Spring Integration.
There was a problem hiding this comment.
I guess something like
build/asciidocwould work as well, but thensourceDirproperty of theasciidoctorjplugin might not be happy.
Still, the full absolute path will be considered. This is a quirk of Gradle. The default path sensitivity is absolute.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This sets the path sensitivity to relative for the
sourceDirproperty of theasciidoctorPdftask. Previously, the full absolute path to the source directory would be considered as an input to the task. This would cause a local build cache miss when executing the task from two different directories or a remote build cache hit given that the paths to the sources directory on CI and for local developers will undoubtedly be different.You can recreate this with the Gradle Enterprise Build Validation Scripts using the following command:
Looking at the task inputs comparison we can see the difference: https://ge.solutions-team.gradle.com/c/2dq5dfpctwmlc/7zthc3fpbm2m4/task-inputs?cacheability=cacheable,overlapping-outputs,validation-failure
Using the diffoscope tool we can see the only difference for the generated
index.pdfis in the creation and modification dates:See also: spring-projects/spring-amqp#2520