Gradle is very powerful build automation tool. It supports numerous languages, has a wide array of plugins to choose from, or write your own, easily manage dependencies, and integrates with the build systems such as Jenkins. Gradle makes it very easy to execute common build tasks and even execute commands on the operating system shell.
As popularity of Gradle has increased, the frequency of new versions is also increasing. In a continuous integration environment it’s important that changes are tested before being rolled out. A common changes is a upgrading the version of Gradle being used to be build your application or project.
The Jenkins Gradle Plugin allows a Gradle installation to be configured on each build node. You can specify where the installation is located or have the plugin download Gradle and install when it’s needed. If you’re Jenkins environment is large, say 15 servers, the upgrade process can be time intensive as well as configuring potentially numerous jobs to use the new version.
Gradle has provides a handy file (well, two files really) to take care of these issues. The Gradle Wrapper is a shell or batch script that specifies what version of Gradle is to be used. The Jenkins plugin for Gradle even allows you to specify if the job should use Gradle already installed on the server, or download and install Gradle based on the wrapper configuration so you don’t need to pre-install Gradle.
Say you need to rebuild your project from an old tag. When that tag went through Jenkins you were using an old version. Now, you’re several major versions ahead and the build no longer works! Using the Gradle Wrapper you version control the version of Gradle your build automation tool is using and help to ensure that the environment configured properly.
