Is gradlew mandatory for travis CI to work?

Question

I'm trying to setup CI for a project that I'm working on, and I'm wondering if we really need to commit the gradlew and/or the gradle.bat files to make it work.

Is there a workaround for this, or committing those files is the only way?

Answer 1

Committing the gradlew script is not mandatory to build a Gradle project in Travis CI.

Probably the best alternative is to use the pre-installed Gradle to install a Gradle wrapper. This is how a simple build.gradle looks like:

apply plugin: 'java'

check.doFirst {
    println "Running gradle v${project.gradle.gradleVersion}"
}

task wrapper(type: Wrapper) {
    gradleVersion = '3.4.1'
}

If you use this build file with the standard Travis descriptor, it won't work. It will simply use gradle to run your build. However if you add the wrapper task to the descriptor:

language: java
jdk:
  - oraclejdk8
before_install:
  gradle wrapper

Travis will run the wrapper task first and then correctly detect that gradlew is present and use it to run your build.

However this approach has a disadvantage that can break your build. If you use some features in Gradle that were implemented after the pre-installed Gradle version, the gradle wrapper step will fail. Example of such feature is the S3 maven repository, that was introduced in v2.4 I believe.

To prevent this, you can move the wrapper task to a separate build file, let's say wrapper.gradle:

task wrapper(type: Wrapper) {
    gradleVersion = '3.4.1'
}

And change the .travis.yml file to:

language: java
jdk:
  - oraclejdk8
before_install:
  gradle -b wrapper.gradle wrapper

This should do it. This setup uses the pre-installed Gradle to install the wrapper without changing your main build script.

You can see an example build here and this is the whole GitHub repository.

---

Note: There is another way. You could use the before_install step to install required Gradle version from a downloadable distribution or maybe using the Debian package system. However that would need sudo privileges. Such virtual machines take long time to start (around 30s?).

Another thing, I mentioned it in a comment on another answer, if you commit the gradlew script, you also need the wrapper jar and properties. The jar is a binary file and putting it in version control is sometimes seen as controversial. So if you use the solution described above, you can also omit committing the gradle folder.

Answer 2

It's not mandatory because it's already pre-installed for Java and Android projects.

However, it's the recommended way to go because the installed version depended on the date when the virtual machine was created, probably outdated.

You can try it and check the version with gradle --version command.

---

Update #1

I demonstrated that my answer is correct forking your MaterialSearchView:

Gradle version 2.2.1 is already pre-installed, so Gradle wrapper is not mandatory, but it's the recommend way to go because your project requires version 2.14.1.

script:
  - gradle clean build

I also demonstrate that the selected answer as correct is based on a wrong assumption. Try to use an unnecessary file and break a build doesn't make this file mandatory, only don't use it and remove chmod line.

You can check here required Gradle version for each Gradle plugin version, in your case plugin version 2.2.3 needs Gradle 2.14.1+

Answer 3

Yes, these files are required.

I determined this with a little trial and error. I deleted them from a branch on one of my personal projects and pushed them up to GitHub, and the travis build failed.

If you are curious what the log looks like, check this gist.

As you can see near the bottom, this is the failing error:

chmod: cannot access `gradlew': No such file or directory
The command "chmod +x gradlew" failed and exited with 1 during .

Minor edit: I tried using it with the gradlew file but not the gradlew.bat file. This worked for a simple clean/build, but when Travis tried to start an emulator, it hung for over 10 minutes.

TL;DR use both files.