Hey folks. How does

@PathSensitive

work with output file properties? I have this task here:

abstract class DownloadSomethingTask : DefaultTask() {
  @get:Input
  abstract val filepaths: ListProperty<String>
  
  @get:OutputFiles
  val outputFiles: Provider<List<RegularFile>> = ... // computed from filepaths
}

I'm seeing issues where running an instance of a task gives

UP-TO-DATE

, indicating that no files were downloaded, and probably in need of a fix on that front.

IIRC outputs don’t need

@PathSensitive

Takes

filepaths

and downloads files from some remote, each to an output location;

outputFiles

is computed from filepaths, indicating which each input file path corresponds to which output file.

Looks to me like you don’t have “input” files in the Gradle sense

Those are just file paths, yes.

Try removing the

@get:Input

IMO it's always a good idea to annotate inputs and outputs properly. If the task always needs to re-execute, you can annotate the task class with

@UntrackedTask

. https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/UntrackedTask.html Martin is right that when you're downloading something, you don't know if the remote resource has changed, so it should opt-out of incremental building and build caching. Unless there is some value you can use to "reasonably assume" the remote resource hasn't changed, like the version number of a GitHub release.

Yeah, it's probably better for me to leave it untracked. I think someone had an impression that the inputs would be so dynamic as to imply that if the output file locations point to files that exist, it implies that it is up to date or somesuch. Weird logic, but it's better to have none of it.

I think the issue is that if the inputs didn't change, there is an assumption that the output files exist, which I have to break somehow since that might not be true.

Should not be the case, unless you used something like

outputs.upToDateWhen { true }

or similar. A task is only considered up-to-date if the inputs did not change, the outputs did not change, and the classpath / implementation of the task did not change. But yeah, if it depends on external input it is most often to mark the task untracked, but still have the inputs and outputs annotated properly, for example to wire task inputs and outputs together properly.