持续构建允许在文件输入发生变化时自动重新执行请求的任务。您可以使用 -t--continuous 命令行选项以这种模式执行构建。

例如,您可以通过运行以下命令来持续运行 test 任务及所有相关任务:

$ gradle test --continuous

当对属于所请求任务的源文件或测试文件进行更改后,Gradle 将表现得如同您运行了 gradle test。这意味着不相关的更改(例如构建脚本的更改)不会触发重新构建。要合并构建逻辑更改,必须手动重新启动持续构建。

持续构建使用文件系统监听来检测输入的变化。如果文件系统监听在您的系统上不起作用,那么持续构建也无法工作。特别是,当使用 --no-daemon 时,持续构建无法工作。

当 Gradle 检测到输入变化时,它不会立即触发构建。相反,它会等待一段时间(静默期),直到没有检测到额外的变化。您可以通过 Gradle 属性 org.gradle.continuous.quietperiod 以毫秒为单位配置静默期。

终止持续构建

如果 Gradle 连接到交互式输入源(例如终端),可以通过按 CTRL-D 退出持续构建(在 Microsoft Windows 上,在按下 CTRL-D 后还需要按 ENTERRETURN)。

如果 Gradle 未连接到交互式输入源(例如,作为脚本的一部分运行),则必须终止构建进程(例如,使用 kill 命令或类似命令)。

如果通过 Tooling API 执行构建,则可以使用 Tooling API 的取消机制来取消构建。

局限性

在某些情况下,持续构建可能无法检测到输入的更改。

创建输入目录

有时,由于文件系统监听的工作方式,创建以前不存在的输入目录不会触发构建。例如,创建 src/main/java 目录可能不会触发构建。同样,如果输入是过滤文件树并且没有文件与过滤器匹配,则创建匹配文件可能不会触发构建。

未跟踪任务的输入

未跟踪任务或没有输出的任务的输入进行更改可能不会触发构建。

项目目录之外文件的更改

Gradle 只监视项目目录内文件的更改。项目目录之外的文件的更改将不被检测到,也不会触发构建。

构建循环

Gradle 在任务执行前开始监视更改。如果一个任务在执行时修改了它自己的输入,Gradle 将检测到该更改并触发新的构建。如果每次任务执行时,输入再次被修改,构建将再次被触发。这并非持续构建所独有。一个修改自己输入的任务在“正常”运行(没有持续构建)时,永远不会被认为是最新状态。

如果您的构建进入了这样的构建循环,您可以通过查看 Gradle 报告的已更改文件列表来找出任务。在确定每次构建中更改的文件后,您应该寻找将该文件作为输入的任务。在某些情况下,这可能很明显(例如,Java 文件是用 compileJava 编译的)。在其他情况下,您可以使用 --info 日志来查找由于已识别文件而导致过期的任务。

通常,Gradle 不会检测符号链接或通过符号链接引用的文件的更改。

不考虑构建逻辑的更改

当前的实现不会在后续构建中重新计算构建模型。这意味着任务配置的更改或构建模型的任何其他更改实际上都会被忽略。

IDE 中的持续构建

大多数现代 IDE,如 IntelliJ IDEAAndroid StudioEclipse,都已提供了自己的持续编译和测试执行形式。

例如,如果您只对文件更改时触发某些操作(例如,运行测试或生成文档)感兴趣,您可以考虑使用 IntelliJ 的 File Watchers 功能作为特定任务的替代方案。

Gradle 的 --continuous 模式是为命令行使用而设计的,并且通常不集成到 IDE 工作流中。要在 IDE 环境中使用持续构建,请从终端窗口(与 IDE 并行)运行 ./gradlew <task> --continuous