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

Use Relative Sensitivity for GenerateProtoTask, use name only sensitivity for classpath. #293

Merged
merged 3 commits into from
Jan 30, 2019

Conversation

runningcode
Copy link
Contributor

Using absolute sensitivity does not allow this task output to be re-used
across different machines.

Classpath jars and files can be located in different parts of the
filesystem relative to the current working directory so the task output
is not cacheable unless we use NAME_ONLY sensitivity.

…vity for classpath.

Using absolute sensitivity does not allow this task output to be re-used
across different machines.

Classpath jars and files can be located in different parts of the
filesystem relative to the current working directory so the task output
is not cacheable unless we use NAME_ONLY sensitivity.
@runningcode runningcode force-pushed the no/relative-sensitivity branch from d656e12 to d843cc3 Compare January 11, 2019 09:45
@@ -379,7 +380,8 @@ class ProtobufPlugin implements Plugin<Project> {
// 'resources' of the output of 'main', in which the source protos are placed. This is
// nicer than the ad-hoc solution that Android has, because it works for any extended
// configuration, not just 'testCompile'.
inputs.files getSourceSets()[sourceSetOrVariantName].compileClasspath
inputs.files (getSourceSets()[sourceSetOrVariantName].compileClasspath)
.withPathSensitivity(PathSensitivity.NAME_ONLY)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this would also be necessary in setupExtractProtosTask()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added!

Copy link
Contributor Author

@runningcode runningcode Jan 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's actually a lot more places this could possibly be added in setupExtractIncludeProtosTask but I was going for a "one thing at a time" PR. :)

@@ -329,7 +329,8 @@ class ProtobufPlugin implements Plugin<Project> {
task = project.tasks.create(extractProtosTaskName, ProtobufExtract) {
description = "Extracts proto files/dependencies specified by 'protobuf' configuration"
destDir = getExtractedProtosDir(sourceSetName) as File
inputs.files project.configurations[Utils.getConfigName(sourceSetName, 'protobuf')]
inputs.files(project.configurations[Utils.getConfigName(sourceSetName, 'protobuf')])
.withPathSensitivity(PathSensitivity.RELATIVE)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is from configuration and presumably also need to be "NAME_ONLY"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I'm not too familiar with the protobuf configuration. I don't think its a general statement that anything from a "cofiguration" should be name only.
The other NAME_ONLY in the setupExtractIncludeProtosTask was the classpath for the compile dependency which means essentially maven jars. These jars may be located in different local maven caches.
On the other hand some configurations may have Kotlin files which require RELATIVE sensitivity but Java files require NAME_ONLY sensitivity because the java compiler ignores the files path and only looks at the package name.

Anyways, I changed this to be NAME_ONLY sensitivity. Let me know if there are any other changes I can make.

Copy link
Collaborator

@zhangkun83 zhangkun83 Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I fully understand how the files from dependencies are considered by the cache. Take a jar file from compile configuration for example, is the jar as a single file or the individual class files from it considered as the input?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe a jar from the compile configuration would be taken as a single file and should be considered NAME_ONLY so I guess in this case NAME_ONLY is correct.
I wasn't sure if the compile configuration also included java/kotlin source files. If it doesn't then this is correct.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable. Do you know how the Gradle cache check if a directory (just a path, not a file tree) is up-to-date? We currently support such usage for the protobuf configuration (#294)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the PathSensitivity works in a similar way whether a FileTree or a Directory are passed to a tasks inputs. The PathSensitivity only applies to the path of the FileTree or the Directory. It doesn't change how the contents of either are cached.

Here is some more information on task relocatability:
https://guides.gradle.org/using-build-cache/#relocatability

@runningcode
Copy link
Contributor Author

Any thoughts on this?
I'm seeing cache misses in our extractIncludeProto and our generateProto tasks.

Happy to change everything to relative to stay on the safer side for now.

@zhangkun83
Copy link
Collaborator

@runningcode sorry for dropping the ball. I think this is a pretty low-risk change. Have you tested with your local build to verify that it works?

@runningcode
Copy link
Contributor Author

runningcode commented Jan 30, 2019

I agree that I think it's a pretty low risk change. I have tested with a local build and it compiles, but I have not tested remote caching. We only push to our build cache server on CI so I can't verify the changes.

Also, a separate note - when testing - I realized that the GenerateProtoTask depends on a OS specific protoc so looks like the caching for the GenerateProtoTask likely won't be completely fixed with this change, but the ExtractIncludeProto should be fixed!

Copy link
Collaborator

@zhangkun83 zhangkun83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, let's give it a try then.

@@ -359,6 +360,7 @@ class ProtobufPlugin implements Plugin<Project> {
destDir = getExtractedIncludeProtosDir(sourceSetOrVariantName) as File
inputs.files (compileClasspathConfiguration
?: project.configurations[Utils.getConfigName(sourceSetOrVariantName, 'compile')])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this still be compile or should it be changed to implementation?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was changed a long time ago in #366

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

Successfully merging this pull request may close these issues.

3 participants