Gradle Study (vii)--Continuous construction

Reprint Please specify source: http://blog.csdn.net/lastsweetop/article/details/78889372

Typically, you will specify the task to be performed for Gradle to execute. Gradle will analyze all the task sets that you are given to perform, execute them all in order, and then stop waiting for your next instruction. Continuous integration is different, it will follow the task instructions you give, constantly analyze whether the build results expire, if the expiration will be executed again, unless you force it to stop. For example, your task is to compile the Java source file into a class file, and when the Java source file changes, the build will automatically execute again. Start and stop

When your gradle task adds –continuous or-t, the ongoing build begins, and it performs the build task first, such as the output of Gradle build-x test-t as follows:

Continuous build is an incubating feature.

BUILD successful in 0s
4 actionable tasks:4 up-to-date

waiting for changes to input files of the tasks ... (Ctrl-d to exit)
<-------------> 0% waiting
> IDLE

Notice that there is no exit instruction after the build is over, it waits for the input file to change, once it changes, it executes the build again, tries to change a groovy file, and then sees the following output:

Continuous build is an incubating feature.

BUILD successful in 0s
4 actionable tasks:4 up-to-date

waiting for changes to input files of the 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 the tasks: . (Ctrl-d to exit)
<-------------> 0% waiting
> IDLE

You can see that the file changes were detected and the build was executed again. The exit method also gives the only simple ctrl-d at present. trigger to build again

Note that the build will be executed again only if the input file of the task changes. Other, whether the build script, the build logic, including the build configuration phase of the file changes will not cause a re-build, such a build must be manually executed before it takes effect.

Take the Gradle Java plugin as an example to illustrate the conditions for building the trigger again, here is the Java Plugin task map:

The following are the input files for each task:

Compilejava
Src/main/java

processresources
src/main/resources

compiletestjava
src/ Test/java

processtestresources
src/test/resources

Assuming that the first build is successful, changing the files in the Src/main/java will happen again, and the incremental build will guarantee that only the build tasks associated with the modifications will be executed.

If the Compilejava task fails, the file changes in time Src/test/java, the build will not be triggered again, because the test task is based on the compilation task, only when the source code modification, the compilation task is built again, the compilation task passed normally, The build of the test task will not be executed again.

The input file that is built is not only the source code, but also possibly other files, such as the processresources input file is a resource file under Src/main/resources, once the resource file changes processresources The task will be executed again.