I’m trying to react to the output of a Copy task, after all filters and renames. But the copyTask.outputs.file only returns the base directory which was being copied, and not the individual files which were outputted. I’ve run into this a few times and it’s definitely a source of headaches. Is considered a bug? Is there a JIRA to track this problem? There are other posts to the forums where people report this problem. One use-case would be cleaning the output of a Copy task, but not deleting the entire directory since the directory is shared by other files (from other copies or from the user). Another use case would be to apply more complex ACL permissions than what fileMode provides.
Is considered a bug?
Not strictly. The ‘outputs.files’ property has to be a forward declaration for certain mechanisms to work. This is not feasible unless the definition of what to copy is 100% declarative and we aren’t there yet. Therefore, the approximation.
So it’s not a bug, but you could argue it’s a shortcoming (and then you could argue I’m splitting hairs, but it does matter).
Is there a JIRA to track this problem?
Not that I’m aware of.
One use-case would be cleaning the output of a Copy task, but not deleting the entire directory since the directory is shared by other files (from other copies or from the user).
It’s unlikely this will ever work in practice unless the definition of what to copy is entirely declarative. Otherwise, we have to actually copy the files in order to work out what’s copied and then it would just be ‘Sync’.
Another use case would be to apply more complex ACL permissions than what fileMode provides.
This could be done other ways, quicker. It would be easier to add some kind of after copy callback into the copy spec machinery that allowed you to do this.