Le démon de construction de Gradle a disparu de manière inattendue (il peut avoir été tué ou s'est écrasé) lors de la construction du projet Android sur Jenkins

Question

J'ai un projet Android qui se construit avec succès sur Android Studio.

Maintenant, je veux le construire sur Jenkins. Mais quand je le fais, j'ai eu l'erreur suivante: le démon de construction Gradle a disparu de manière inattendue (il a peut-être été tué ou s'est é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)
 

J'ai lu des sujets connexes, mais cela n'aide pas. J'ai essayé de le construire en utilisant le démon gradle, et sans lui, mais le problème existe toujours.

Answer 1

EDIT Semble qu'il y a eu quelques changements avec les nouvelles versions de Gradle.

Depuis la version 3.0, vous devez pas désactiver le démon sur votre CI plus

[Nous] nous vous recommandons d'utiliser [le démon] pour les développeurs de machines et de serveurs d'Intégration Continue.

Toutefois, si vous pensez que le Démon fait votre CI s'appuie instable, vous pouvez le désactiver pour utiliser un nouveau moteur d'exécution pour chaque version, puisque le moteur d'exécution est complètement isolé de tout les versions précédentes.

RÉPONSE PRÉCÉDENTE

Il est recommandé de désactiver daemon sur n'importe quel serveur CI. utilisez cette option pour le désactiver

--no-daemon

Answer 2

Après cet incident, j'ai essayé plusieurs choses pour obtenir le GradleDaemon d'arrêter de courir sur mon serveur CI. Aucun n'a fonctionné.

J'ai trouvé une réponse sur un gradle.org forum qui a suggéré que le GradleDaemon serait toujours fonctionner de toute façon. L'option --no-daemon drapeau serait juste de le faire fonctionner pour ce construire, plutôt que de rester indéfiniment.

Si vous préciser des arguments JVM qui nécessitent une bifurcation, Gradle déviera une nouvelle JVM. Peu importe si vous voulez ou non un processus de démon, la classe qui s'exécute est appelé GradleDaemon. L'option --no-daemon commutateur doit provoquer la fourche processus à usage unique au lieu d'une longue course du processus de démon, mais il est toujours en cours pour exécuter le GradleDaemon classe.

Source: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5

J'ai peut-être la lecture de ce mal et je ne peux pas se porter garant de la validité de la réponse, mais je pense que la cause de cette erreur est juste un manque de mémoire pour Gradle. Comme il est toujours exécuter le GradleDaemon.

J'ai donc ajouté

org.gradle.jvmargs=-Xmx1024m 

pour ma ~/.gradle/gradle.properties le fichier et il ne me procurait plus de cette erreur.

Answer 3

Il semble que c'est une mémoire liée au problème. Néanmoins, la désactivation du démon comme suggéré par Oleg ne semble pas aider.

Utilisation

org.gradle.daemon=false

dans

gradle.propriétés

soit dans ~/.gradle dossier ou le projet du dossier.

Ref: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

Answer 4

Dans notre cas, le problème était dû au fait que le serveur CI passait 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 Gradle a résolu le problème immédiatement.

Answer 5

Gradle build daemon disappeared unexpectedly dans de nombreux cas, cela signifie que Gradle lui-même ou même Java s'est écrasé. Dans mon cas, c'était java . Rapport de bogue rempli: https://bugzilla.redhat.com/show_bug.cgi?id=1408857

Regardez 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 que vous exécutez.