Incremental input NOT dependent on filename?

If I use the @Input annotation on a file, it indicates that the task is dependent on the path to that file, but not the contents of the file.

If I use the @InputFile (or @InputFiles) annotation, it indicates that the task is dependent on the path and contents of the file.

What if I wanted to make a task dependent on the content of a file, but not the path to the file? Depending on how the file is processed, the name of the file might not matter. For example, if the input file changed from foo-1.0.1.txt to foo-1.0.2.txt, but the contents were unchanged, then for a particular task, it might make sense to consider it up-to-date (or to retrieve it from the build cache, etc.).

Interestingly, this case can be handled for build outputs. For example, if a task output was changed from bar-1.0.1.txt to bar-1.0.2.txt, but all the tasks inputs remained the same, then the contents of bar-1.0.1.txt could be retrieved from the build cache and used to create bar-1.0.2.txt. I believe that’s in part because outputs can be identified as a map, identifying which outputs are which files, regardless of the filenames involved.

Is there any way to achieve the same thing with task inputs? This would be a real benefit in a particular use case I’m facing.

Hi Bob,

that is the reason for the @PathSensitive annotation. For your use-case (only contents), you would need to annotate your inputs with @InputFile and @PathSensitive(PathSensitivity.NONE). For more explanations, you can also check the build cache guide or the userguide.




I had encountered that before, but that not realized that sensitivity could go as low as NONE. Thank you!


Perhaps you can answer one thing for me: If I annotate a method with @InputFiles and @PathSensitive(PathSensitivity.NONE), do I need to ensure that the files as returned in the list from the method are always in the same order? That is, if I return [foo, bar] once and then [bar, foo], another time, will that change the build cache key?

It seems to me to be likely that it would, but perhaps Gradle has a sneaky way around that.


The comparison between input files and the build cache key does not depend on the order, no matter what path sensitivity is used. Only for @CompileClasspath and @Classpath, the order is taken into account.