Le démon de construction Gradle a disparu de façon inattendue (il peut avoir été tué ou s'est écrasé) lors de la création du projet Android sur Jenkins
J'ai un projet Android qui construit avec succès sur Android Studio.
Maintenant, je veux le construire sur Jenkins. Mais quand je le fais, j'ai le message d'erreur suivant: Le démon de construction Gradle a disparu de manière inattendue (il peut avoir été tué ou s'est peut-être écrasé)
L'exception est:
org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
at org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.Java:222)
at org.gradle.launcher.daemon.client.DaemonClient.monitorBuild(DaemonClient.Java:198)
at org.gradle.launcher.daemon.client.DaemonClient.executeBuild(DaemonClient.Java:162)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.Java:125)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.Java:80)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.Java:43)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.Java:173)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.Java:241)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.Java:214)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.Java:35)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.Java:24)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.Java:207)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.Java:169)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.Java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.Java:22)
at org.gradle.launcher.Main.doAction(Main.Java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.Java:45)
at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:62)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43)
at Java.lang.reflect.Method.invoke(Method.Java:498)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.Java:55)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.Java:36)
at org.gradle.launcher.GradleMain.main(GradleMain.Java:23)
Je lis des sujets connexes, mais cela n’aide en rien. J'ai essayé de le construire en utilisant gradle daemon, mais sans le problème, mais le problème existe toujours.
EDIT On dirait que quelques modifications ont été apportées aux nouvelles versions de Gradle.
Depuis la version 3.0, vous devriez ne plus désactiver le démon de votre CI
Nous recommandons d'utiliser [le démon] pour les machines des développeurs et les serveurs d'intégration continue.
Toutefois, si vous pensez que Daemon rend vos générations de CI moins stables, vous pouvez le désactiver pour utiliser un nouveau runtime pour chaque build, car celui-ci est complètement isolé des précédentes.
RÉPONSE PRÉCÉDENTE
Il est recommandé de désactiver daemon sur tout serveur de CI . utilisez cette option pour le désactiver
--no-daemon
Il semble que ce soit un problème lié à la mémoire. Néanmoins, désactiver le démon comme suggéré par Oleg semble aider.
Utilisation
org.gradle.daemon = false
dans
gradle.properties
soit dans le dossier ~/.gradle ou dans le dossier du projet.
Réf.: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon
Après avoir eu ce crash, j'ai essayé plusieurs choses pour que GradleDaemon cesse de fonctionner sur mon serveur CI. Aucun de ce qui a fonctionné.
J'ai trouvé une réponse sur un forum de Gradle.org qui suggérait que le GradleDaemon fonctionnerait toujours de toute façon. Le drapeau --no-daemon le ferait juste pour cette construction spécifique plutôt que de rester indéfiniment.
Si vous spécifiez des arguments de machine virtuelle nécessitant un forking, Gradle crée une nouvelle machine virtuelle. Que vous souhaitiez ou non un processus démon, la classe qui s'exécute s'appelle GradleDaemon. Le commutateur --no-daemon devrait faire en sorte que le processus créé soit à usage unique au lieu d'un processus long, mais qu'il continuera d'exécuter la classe GradleDaemon.
Source: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5
J'ai peut-être mal lu et je ne peux pas garantir la validité de la réponse, mais je pense que la cause de cette erreur est simplement un manque de mémoire pour Gradle. Comme il va toujours exécuter le GradleDaemon.
Alors j'ai ajouté
org.gradle.jvmargs=-Xmx1024m
à mon fichier ~/.gradle/gradle.properties et il ne m'a plus donné cette erreur.
Dans notre cas, le problème était dû au fait que le serveur CI a transmis des variables d’environnement avec des caractères non ascii (c’est-à-dire dans les noms des auteurs de commit).
L'ajout de file.encoding=utf-8 aux propriétés de Gradle a résolu le problème immédiatement.
Gradle build daemon disappeared unexpectedly dans de nombreux cas signifie gradle lui-même ou même Java s'est écrasé . Dans mon cas, il était Java. Rapport de bug rempli: https://bugzilla.redhat.com/show_bug.cgi?id=1408857
Examinez les fichiers nommés comme: hs_err_pid%p.log où% p est le PID du processus dans le répertoire à partir de la tâche gradle.
J'ai essayé la solution --no-daemon mais ma construction a continué à échouer avec le même DaemonDisappearedException.
J'ai résolu ce problème en augmentant la RAM du serveur sur lequel je lance Jenkins. Dans AWS EC2, cela signifiait qu'il fallait augmenter le type d'instance EC2, ce qui entraînait une augmentation de la RAM.
Personne d'autre ne peut se heurter à cela, car c'est assez idiot, mais ...
Mon problème était un un caractère étrange était présent dans mon message de validation ... J'avais copié un précédent message de validation de gitlab qui contenait un emoji et l'avait collé dans le titre d'une demande de fusion au lieu de la syntaxe normale :bug:.
la réponse d'Akru m'a aidé à me diriger dans la bonne direction ????
gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug
Ou ajoutez org.gradle.jvmargs=-Xmx1536m au fichier gradle.properties .
Dans mon cas, je mettais à niveau mon projet de studio Android et j’utilise ZelixKlassMaster pour masquer mon code car j’avais mon chemin de classe sur Zelix défini sur 27 mais mon projet utilisait Android 28. J'espère que cela aidera tout futur visiteur j'ai débogué c'était mon fichier seed imprimant cette erreur
ERROR: Invalid classpath in "classpath" statement at line 69 : "C:\Users\Rab\AppData\Local\Android\Sdk\platforms\Android-27\Android.jar" is not a valid path.
J'utilisais Android Studio sous Windows 7, puis cette erreur est apparue. Ce qui a fonctionné pour moi est de tuer Java.exe à partir de Windows TaskManager.
Parfois, il suffit d'essayer Construire -> Nettoyer le projet - Essayez-le avant de commencer avec les autres modifications apportées au fichier Gradle.