Gradle Commands

gradle commands cheatsheet.

Build, run, test and inspect — the Gradle wrapper commands you use every day. Tap to copy.

Build & run
./gradlew buildCompile, test and assemble the whole project
./gradlew assembleBuild the outputs without running tests
./gradlew runRun the application (application plugin)
./gradlew cleanDelete the build directory
./gradlew clean buildClean then do a full fresh build
Test
./gradlew testRun the unit tests
./gradlew test --tests <pattern>Run only tests matching a pattern
./gradlew checkRun all verification tasks (tests, linters)
Tasks & inspection
./gradlew tasksList the available tasks
./gradlew <task>Run a specific task by name
./gradlew dependenciesShow the dependency tree
./gradlew propertiesShow the project's properties
./gradlew projectsList the projects in the build
Flags
./gradlew build --infoShow info-level log output
./gradlew build --stacktracePrint a full stacktrace on failure
./gradlew build --offlineBuild without network access
./gradlew build --no-daemonRun without the background daemon
./gradlew build -x testExclude a task from the run (skip tests)
./gradlew build --refresh-dependenciesRe-download and refresh dependencies
Wrapper & info
./gradlew wrapper --gradle-version <v>Set the wrapper's Gradle version
gradle --versionShow the installed Gradle version
./gradlew --helpShow command-line help

What Gradle actually does

Gradle is a build automation tool used across the JVM world — Java, Kotlin, Android and more — to compile code, run tests, and package artifacts. Its build is described in a build.gradle (or build.gradle.kts) file that declares plugins, dependencies and tasks. The command you reach for most is ./gradlew build, which compiles your sources, runs the tests, and assembles the outputs in one go — the first thing you'll run on almost any project.

Why ./gradlew, not gradle

Most projects ship a wrapper: a small ./gradlew script (gradlew.bat on Windows) plus a version file checked into the repo. Running ./gradlew instead of a globally installed gradle downloads and uses the exact Gradle version the project expects, so everyone — and your CI — builds with the same toolchain. Prefer the wrapper form whenever it exists; reach for a system gradle only to bootstrap a brand-new project or to check gradle --version.

Tasks and testing

Everything Gradle does is a task. Run ./gradlew tasks to see what's available, then invoke one by name with ./gradlew <task>. Tests run with ./gradlew test, and you can narrow to a single class or method with ./gradlew test --tests <pattern>. The broader ./gradlew check runs tests plus any configured verification like linting, and ./gradlew dependencies prints the full resolved dependency tree when versions clash.

Handy flags

A few flags make builds easier to live with. --info and --stacktrace surface more detail when something breaks, --offline avoids the network, and -x <task> excludes a task (for example -x test to skip tests). When dependency caches go stale, --refresh-dependencies forces a re-download. These pair naturally with the Git commands for version control and the Docker commands when you containerise your app.

FAQ

What's the difference between gradle and ./gradlew?
gradle uses whatever Gradle is installed on your machine, while ./gradlew is the wrapper checked into the project — it downloads and runs the exact Gradle version the project expects, so builds are reproducible for everyone.
How do I run a single test?
Use ./gradlew test --tests <pattern>, for example ./gradlew test --tests 'com.example.MyTest' or a method like 'com.example.MyTest.myMethod'. Wildcards such as '*MyTest' also work.

More cheatsheets