在Jenkins上构建Android项目时,Gradle构建守护程序意外消失(可能已被杀死或可能已崩溃)

Question

我有一个在Android Studio上成功构建的Android项目.

现在我想在Jenkins上构建它.但是当我正在做的时候我得到了以下错误:Gradle build daemon意外地消失了(它可能已被杀死或可能已经崩溃)

例外情况是:

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)

我阅读了相关主题,但没有用.我尝试使用gradle守护进程构建它,没有它,但问题仍然存在.

Answer 1

编辑看起来Gradle的新版本有一些变化.

从3.0开始,您不应再禁用CI上的守护程序

[我们]建议将[守护程序]用于开发人员的计算机和持续集成服务器.

但是,如果您怀疑Daemon使您的CI构建不稳定,则可以禁用它以为每个构建使用新的运行时,因为运行时与任何以前的构建完全隔离.

以前的答案

建议关闭daemon任何CI服务器.使用此选项可禁用它

--no-daemon

Answer 2

在遇到这次崩溃之后,我尝试了几件事让GradleDaemon停止在我的CI服务器上运行.这些都没有奏效.

我在gradle.org论坛上找到了答案,该论坛表明GradleDaemon无论如何都会一直运行.--no-daemon标志只会让它为这个特定的构建运行而不是无限期地继续运行.

如果指定需要分叉的JVM参数,Gradle将分叉一个新的JVM.无论您是否需要守护程序进程,运行的类都称为GradleDaemon.--no-daemon开关应该使forked进程单独使用而不是长时间运行的守护进程,但它仍然会运行GradleDaemon类.

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

我可能正在读错了,我不能保证答案的有效性,但我认为这个错误的原因只是Gradle的内存不足.因为它总是会运行GradleDaemon.

所以我补充道

org.gradle.jvmargs=-Xmx1024m 

到我的~/.gradle/gradle.properties文件,它不再给我这个错误.

Answer 3

随着人们转向 GitHub 工作流程和 GitHub Actions，此类问题（Gradle 构建守护进程意外消失（它可能已被终止或可能已崩溃））似乎变得越来越常见。

在本地构建（命令行或 Android Studio）或在 Jenkins 构建服务器上构建时，我们从未遇到过此问题。但一旦我们开始通过 GitHub Workflows/Actions 测试构建，这种类型的构建错误就会间歇性地发生。

每个项目都是不同的，因此似乎有几种可行的解决方案。经过对我们的构建进行大量实验后，唯一可靠地解决此问题的参数是“ -XX:MaxMetaspaceSize ”。

GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

在我们的案例中，不需要更改 build.gradle、gradle.properties、gradle-wrapper.properties 等。只是我们的 GitHub 工作流程 yaml 中的单个 GRADLE_OPTS 行。Java 文档中的这个解释是最有帮助的（避免类元数据空间的无限增长）。

在 Java Hotspot VM 的早期版本中，类元数据分配在所谓的永久代中。从 JDK 8 开始，永久代被删除，类元数据在本机内存中分配。默认情况下，可用于类元数据的本机内存量是无限的。使用该选项-XX:MaxMetaspaceSize可以设置用于类元数据的本机内存量的上限。

来源：https ://docs.oracle.com/en/java/javase/17/gctuning/other-considerations.html

GitHub 工作流程的工作示例：

jobs:
  build:

    runs-on: ubuntu-latest

    env:
      GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

    steps:
    - uses: actions/checkout@v2
      with:
        ref: 'master'
        fetch-depth: 0

    - name: Set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Gradle Build
      uses: gradle/gradle-build-action@v2
      with:
        arguments: build -x lint appDistributionUploadRelease

Answer 4

这似乎是一个与内存相关的问题.尽管如此,按照Oleg的建议禁用守护进程似乎也有帮助.

使用

org.gradle.daemon = FALSE

在

gradle.properties

在〜/ .gradle文件夹或项目的文件夹中.

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

Answer 5

在我们的例子中,问题是由CI服务器传递具有非ascii字符的环境变量(即在提交作者的名称中)引起的.

添加file.encoding=utf-8到Gradle属性会立即修复问题.

Answer 6

gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

或者添加org.gradle.jvmargs=-Xmx1536m到gradle.properties 文件。

Answer 7

其他人可能不会遇到这种情况，因为这很愚蠢，但是......

我的问题是我的提交消息中出现了一个奇怪的字符...我从 gitlab 复制了之前的提交消息，其中包含表情符号并将其粘贴到合并请求的标题中，而不是正常的:bug:语法。

阿库鲁的回答帮助我指明了正确的方向