5
votes

Impossible de créer un service de type FileHasher à l'aide de GradleUserHomeScopeServices.createCachingFileHasher ()

Voici le contexte de mon problème:

  • un pipeline yml gitlab ci
  • plusieurs emplois dans le même stage
  • tous les jobs utilisent un gradle de tâche nécessitant l'utilisation de son cache
  • toutes les tâches partagent le même cache gradle

Mon problème:

Parfois, quand il y a plusieurs pipelines en même temps, j'obtiens:

Qu'est-ce qui ne va pas: Impossible de créer un service de type FileHasher à l'aide de GradleUserHomeScopeServices.createCachingFileHasher ().

Délai d'attente pour verrouiller le cache de hachage des fichiers (/cache/.gradle/caches/5.1/fileHashes). Il est actuellement utilisé par une autre instance Gradle. PID propriétaire: 149 Notre PID: 137 Fonctionnement du propriétaire: Notre opération: Verrouiller le fichier: /cache/myshop/reunion/.gradle/caches/5.1/fileHashes/fileHashes.lock

Je ne trouve aucune documentation sur le système de verrouillage utilisé par gradle. Je ne comprends pas pourquoi les verrous sont positionnés lorsque l'action gradle n'écrit pas dans le répertoire du cache.

Quelqu'un sait-il comment fonctionnent les serrures? Ou puis-je simplement modifier la durée du délai d'expiration pour permettre aux tâches concomitantes d'attendre leur tour suffisamment longtemps avant d'échouer?

Traduit avec www.DeepL.com/Translator

J'ai essayé de régler gradle sans démon, cela n'a pas fonctionné.


0 commentaires

3 Réponses :


6
votes

Vous obtenez généralement cette erreur lorsque vous essayez de partager le cache Gradle entre plusieurs processus Gradle qui s'exécutent sur différents hôtes. Je suppose que vos pipelines CI fonctionnent sur des hôtes différents ou qu'ils fonctionnent au moins isolés les uns des autres (par exemple, dans le cadre de différents conteneurs Docker).

Malheureusement, un tel scénario n'est pas actuellement pris en charge par Gradle. Le développeur de Gradle Stefan Oehme a écrit ce commentaire écrit. partage de la maison de l'utilisateur Gradle:

Les processus Gradle maintiendront des verrous s'ils ne sont pas sollicités (pour gagner en performances). Les conflits sont annoncés via la communication inter-processus, qui ne fonctionne pas lorsque les processus sont isolés dans des conteneurs Docker.

Et plus clairement, il déclare dans un commentaire de suivi ( mise en évidence par moi):

Il peut y avoir d'autres problèmes que nous n'avons pas encore découverts, car le partage du domicile d'un utilisateur entre des machines n'est pas un cas d'utilisation pour lequel nous avons conçu .

En d'autres termes: le partage d'un domicile utilisateur Gradle ou même simplement de la partie cache de celui-ci sur différentes machines ou processus isolés n'est actuellement pas officiellement pris en charge par Gradle. (Voir également ma question connexe .)

Je suppose que la seule façon de résoudre ce problème pour votre scénario est de:

  • assurez-vous que les processus Gradle de vos pipelines CI peuvent communiquer entre eux (par exemple, en les exécutant sur le même hôte), ou
  • ne partagez pas directement la page d'accueil de l'utilisateur Gradle, par exemple en créant des copies pour tous les pipelines CI, ou
  • ne pas exécuter les pipelines CI en parallèle.

0 commentaires

4
votes

J'ai résolu ce problème en supprimant tous les processus java dans Activity Monitor (MacOS). J'espère que cela aide.


1 commentaires

Exactement!! ça ne marche que pour moi! En fait, j'ai redémarré le mac sans trouver tous les processus java et les tuer. Paresseux!! Cela a commencé à fonctionner.



0
votes

Un autre scénario où cela pourrait se produire est si certains de ces fichiers liés à Gradle sont sur un système de fichiers cloud comme OneDrive qui nécessite une ré-authentification.

  1. Réauthentifiez-vous auprès du système de fichiers cloud
  2. "Invalider les caches et redémarrer" dans Android Studio

0 commentaires