Show 특정 하위프로젝트에 속한 특정 테스트 케이스만 돌리기gradle :subproject:test --tests *VerificationRepositoryTest* 특정 프로필을 활성화하기이 기능은 다음과 같은 전제하에 작동한다.
gradle -Dspring.profiles.active=dev build 애플리케이션 띄우기또는 ./gradlew build && java -jar ./gate/build/libs/gate-spring-0.0.1-SNAPSHOT.jar
|
Some tasks selectors, like |
When invoking Gradle from within a subproject, the project name should be omitted:
$ cd my-subproject $ gradle taskName
When executing the Gradle Wrapper from subprojects, one must reference |
Executing multiple tasks
You can also specify multiple tasks. The tasks will be executed as quickly as possible while still honoring task dependencies. Precise order of
execution is determined by the tasks' dependencies, and a task having no dependencies may execute earlier than it is listed on the command-line. For example, the following will execute the test and deploy tasks in the order that they are listed on the command-line and will also execute the dependencies for each task.
Command line order safety
Although Gradle will always attempt to execute the build as quickly as possible, command line ordering safety will also be honored. For example, the following will execute clean and build along with their
dependencies.
However, the intention implied in the command line order is that clean should run first, and then build. It would be incorrect to execute clean after build, even if doing so would cause the build to execute faster, since clean would remove what build created. Conversely, if the command line order was build followed by clean, it would not be correct to execute clean before build. Although Gradle will execute the build as quickly as
possible, it will also respect the safety of the order of tasks specified on the command line and ensure that clean runs before build when specified in that order.
Note that command line order safety relies on tasks properly declaring what they create, consume or remove. See up-to-date checks for further information.
Excluding tasks from execution
You can exclude a task from being executed using the -x or --exclude-task command-line option and providing the name of the task to
exclude.
Figure 1. Simple Task Graph
Excluding tasks
$ gradle dist --exclude-task test > Task :compile compiling source > Task :dist building the distribution BUILD SUCCESSFUL in 0s 2 actionable tasks: 2 executed
You can see that the test task is not executed, even though it is a dependency of the dist task. The test task’s dependencies such as compileTest are not executed either. Those dependencies of test that are required by another task, such as compile,
are still executed.
Forcing tasks to execute
You can force Gradle to execute all tasks ignoring up-to-date
checks using the --rerun-tasks option:
$ gradle test --rerun-tasks
This will force test and all task dependencies of test to execute. It’s a little like running gradle clean test, but without the build’s generated output being deleted.
Continuing the build when a failure occurs
By default, Gradle will abort execution and fail the build as soon as any task fails. This allows the build to complete sooner, but hides other failures that would have occurred. In order to
discover as many failures as possible in a single build execution, you can use the --continue option.
When executed with --continue, Gradle will execute every task to be executed where all of the dependencies for that task completed without failure, instead of stopping as soon as the first failure is encountered. Each of the encountered failures will be reported at the end of the build.
If a task fails, any subsequent tasks that were depending on it will not be executed. For example, tests will not run if there is a compilation failure in the code under test; because the test task will depend on the compilation task (either directly or indirectly).
Name abbreviation
When you
specify tasks on the command-line, you don’t have to provide the full name of the task. You only need to provide enough of the task name to uniquely identify the task. For example, it’s likely gradle che is enough for Gradle to identify the check task.
The same applies for project names. You can execute the check task in the library subproject with the gradle lib:che command.
You can use camel case patterns for
more complex abbreviations. These patterns are expanded to match camel case and kebab case names. For example the pattern foBa (or even fB) matches fooBar and foo-bar.
More concretely, you can run the compileTest task in the my-awesome-library subproject with the gradle mAL:cT command.
Abbreviated project and task names
$ gradle mAL:cT > Task :my-awesome-library:compileTest compiling unit tests BUILD SUCCESSFUL in 0s 1 actionable task: 1 executed
You can also use these abbreviations with the -x
command-line option.
Tracing name expansion
For complex projects, it might not be obvious if the intended tasks were executed. When using abbreviated names, a single typo can lead to the execution of unexpected tasks.
When INFO, or more verbose logging is enabled, the output will contain extra information about the project and task name expansion. For example, when executing the mAL:cT command on the previous example, the following log messages will be visible:
No exact project with name ‘:mAL’ has been found. Checking for abbreviated names. Found exactly one project that matches the abbreviated name ‘:mAL’: ':my-awesome-library'. No exact task with name ‘:cT’ has been found. Checking for abbreviated names. Found exactly one task name, that matches the abbreviated name ‘:cT’: ':compileTest'.
