持续构建允许您在文件输入更改时自动重新执行请求的任务。您可以使用-t或--continuous命令行选项在此模式下执行构建。
例如，您可以test通过运行以下命令连续运行该任务和所有相关任务：
$ gradle test --continuous
gradle testGradle 的行为就像您在更改有助于请求任务的源或测试后运行一样。这意味着不相关的更改（例如对构建脚本的更改）将不会触发重建。要合并构建逻辑更改，必须手动重新启动连续构建。
持续构建使用文件系统监视来检测输入的更改。如果文件系统监视在您的系统上不起作用，那么连续构建也将不起作用。特别是，使用时连续构建不起作用--no-daemon。
当 Gradle 检测到输入发生更改时，它不会立即触发构建。相反，它将等待一段时间（安静期），直到没有检测到任何其他更改。您可以通过 Gradle 属性以毫秒为单位配置安静期org.gradle.continuous.quietperiod。
终止持续构建
如果 Gradle 连接到交互式输入源（例如终端），则可以通过按退出连续构建CTRL-D（在 Microsoft Windows 上，还需要按ENTER或RETURN之后CTRL-D）。
如果 Gradle 未附加到交互式输入源（例如作为脚本的一部分运行），则必须终止构建过程（例如使用命令kill或类似命令）。
如果通过 Tooling API 执行构建，则可以使用 Tooling API 的取消机制取消构建。
局限性
在某些情况下，连续构建可能无法检测输入的更改。
创建输入目录
有时，由于文件系统监视的工作方式，创建以前丢失的输入目录不会触发构建。例如，创建src/main/java目录可能不会触发构建。同样，如果输入是经过筛选的文件树，并且没有文件与筛选器匹配，则匹配文件的创建可能不会触发构建。
对项目目录之外的文件进行更改
Gradle 仅监视项目目录内文件的更改。对项目目录外部文件的更改将不会被检测到，并且不会触发构建。
构建周期
Gradle 在任务执行之前开始监视更改。如果任务在执行时修改了自己的输入，Gradle 将检测到更改并触发新的构建。如果每次任务执行时，再次修改输入，则会再次触发构建。这并不是持续构建所独有的。在没有持续构建的情况下“正常”运行时，修改其自身输入的任务永远不会被认为是最新的。
如果您的构建进入这样的构建周期，您可以通过查看 Gradle 报告的更改的文件列表来跟踪任务。识别出每次构建期间更改的文件后，您应该查找将该文件作为输入的任务。在某些情况下，这可能是显而易见的（例如，Java 文件是用 编译的compileJava）。在其他情况下，您可以使用--info日志记录来查找由于识别的文件而过期的任务。