转载请注明出处：http://blog.csdn.net/lastsweetop/article/details/78889372

通常情况下，你会指定要执行的任务让Gradle来执行。Gradle会分析你给出的任务需要执行的所有任务集合，按照顺序全部执行他们，然后停下来等你的下一次指令。持续集成则不同，它会按照你给出的任务指令，不断的分析构建结果是否过期，如果过期则会再次执行构建，除非你强制让它停下来。比如你的任务是把java的源文件编译为class文件，那么当java源文件改变时，构建就会自动再次执行。

开始和停止

当你的gradle任务增加了–continuous或者-t时，持续构建便开始了，它会首先执行一次构建任务，例如gradle build -x test -t的输出如下：

Continuous build is an incubating feature. BUILD SUCCESSFUL in 0s 4 actionable tasks: 4 up-to-date Waiting for changes to input files of tasks... (ctrl-d to exit) <-------------> 0% WAITING > IDLE

注意到构建结束之后也没有退出指令，它在等待输入文件的改变，一旦发生改变它就会再次执行构建任务，试着改变一个groovy文件，然后看到如下输出：

Continuous build is an incubating feature. BUILD SUCCESSFUL in 0s 4 actionable tasks: 4 up-to-date Waiting for changes to input files of tasks... (ctrl-d to exit) modified: /Users/apple/Documents/mydream/groovy/studygroovy/src/main/groovy/app/TimeWindow.groovy Change detected, executing build... BUILD SUCCESSFUL in 7s 4 actionable tasks: 2 executed, 2 up-to-date Waiting for changes to input files of tasks... (ctrl-d to exit) <-------------> 0% WAITING > IDLE

可以看到检测到了文件的改变，并再次执行了构建。退出方式也给出了目前只能简单的Ctrl-D。

再次构建的触发

要注意的是，仅仅任务的输入文件改变时，构建才会再次执行。其他的，不管是构建脚本，构建逻辑，包括构建的配置阶段的文件发生改变都不会引起再次构建，这类的构建必须再次手动执行才会生效。

以gradle的java插件为例子来说明一下再次构建触发的条件，以下是java插件任务图：

以下是各个任务对于的输入文件：

compileJava src/main/java processResources src/main/resources compileTestJava src/test/java processTestResources src/test/resources

假设第一次构建已经成功，这时候改变src/main/java里的文件，将会再次发生构建，增量构建将会保证只会执行与修改相关的构建任务。

如果compileJava任务失败，及时src/test/java下的文件发生了改变，构建也不会再次触发，因为测试任务是基于编译任务的，只有当源代码修改，编译任务构建再次执行，编译任务正常通过了，测试任务的构建才会再次执行。

构建的输入文件不仅仅是源代码，还有可能是其他文件，比如processResources的输入文件是src/main/resources下的资源文件，资源文件一旦发生改变processResources任务就会再次执行。