J'ai une unzipData
tâche gradle définie comme suit:Gradle supprime le répertoire défini comme sortie des tâches (répertoires obsolètes)
task unzipFile(type: Copy) {
dependsOn mkdirTrash
dependsOn downloadFile
from zipTree(file("$trashDir/file.zip"))
into trashDir
}
La tâche décompresse le contenu des archives à droite dans le répertoire avec lui-même archive (dans le répertoire trash
, qui est une racine des artefacts de toutes les tâches et qui ne peut être supprimée que lorsque toutes les tâches de préparation sont terminées). Ça fonctionnait jusqu'à ce que je mette à jour le wrapper gradle vers la version 4.2.1.
exécution de la tâche a commencé à produire l'erreur:
FAILURE: Build failed with an exception.
* What went wrong:
Cannot expand ZIP 'trash/file.zip' as it does not exist.
En sortie de débogage je vois que gradle supprime l'ensemble trash
répertoire
> Task :unzipFile
11:56:23.145 [DEBUG] [org.gradle.internal.progress.DefaultBuildOperationExecutor] Build operation 'Task :unzipFile' started
11:56:23.145 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':unzipFile'
11:56:23.145 [INFO] [org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter] Putting task artifact state for task ':unzipFile' into context took 0.0 secs.
11:56:23.204 [DEBUG] [org.gradle.internal.progress.DefaultBuildOperationExecutor] Build operation 'Clean stale outputs' started
11:56:23.204 [INFO] [org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter] Deleting stale output file: /.../trash
Pour autant que je peux voir est nouvelle fonctionnalité de gradle https://docs.gradle.org/4.2-rc-1/release-notes.html#safer-handling-of-stale-output-files
Les docs indiquent que seuls les répertoires sont enregistrés comme cibles pour la tâche propre et les sorties du jeu de sources sont obsolètes. Je suppose, la tâche Copy
est l'un des source set
et sa sortie est liée à être supprimée.
Je me demande quels sont les avantages de cette fonctionnalité? Est-il possible d'interdire le nettoyage de répertoires particuliers? Des solutions de contournement pas sales?
Ceci est probablement dû à la tâche propre automatique 'cleanUnzipFile' créé par gradle. C'est donc en fait un répertoire enregistré pour la tâche 'clean' – Eloff
@Eloff Je doute que la tâche' clean' soit déclenchée au milieu d'une autre tâche exécutée par cette tâche elle-même. Quoi qu'il en soit, rien n'indique que dans la sortie --debug –
La tâche propre n'a pas besoin d'être exécutée, la simple présence de celle-ci fera que Gradle trouvera des "fichiers de sortie périmés" – Eloff