转载请注明出处:http://blog.youkuaiyun.com/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
任务就会再次执行。