Travis runs 'gradle assemble' even if project has custom script section.

[artem-zinnatullin]

According to docs https://docs.travis-ci.com/user/languages/java/#Projects-Using-Gradle

Before running the build, Travis CI installs dependencies:

gradle assemble

or

./gradlew assemble

There are multiple problems with this:

• gradle assemble not only resolves some dependencies, but actually builds all modules in project
• gradle assemble can take significant part of overall build time — minutes, depending on project (this is inefficient for Travis itself, I believe you waste tons of machine time on this every day even in projects that don't need this behavior)
• gradle assemble duplicates significant part of build if user specified script section with gradle clean task in it, basically removing results of gradle assemble run by Travis
• gradle assemble can fail build because project doesn't expect this task to be run, ie Fix Travis CI build. uber/okbuck#547
• gradle assemble consumes important Travis resource — log entries. Travis limits build logs in UI to 10k lines and overall log to 4mb. In our cases, 2-5k (300kb) of logs produced by gradle assemble that we don't need
• gradle assemble is running even if project has custom script section, which is wrong. There are projects that happen to use Gradle but for instance need Docker to actually run it properly, Travis messes up with that. See Composer, Swarmer.

---

TL;TR: please let users disable Travis' "Let's asssume we know how to build user's project better than user" behavior :)

Examples of affected projects (I believe I didn't see this behavior couple months ago):

• Update Gradle 3.1 → 4.2.1, AGP 2.2.1 → 2.3.3, Build Scan plugin 1.3 → 1.10, Retrolambda Plugin 3.7.0, Error Plugin 0.0.8 → 0.0.13. artem-zinnatullin/qualitymatters#226 (see PR description)
• Make CreateWith and InstanceFactory jvm specific spekframework/spek#304 (see PR build)
• Fix Travis CI build. uber/okbuck#547 (see PR build, spent lots of time trying to figure out why I can't setup environment before gradle assemble, turned out project used before_script instead of before_install)

Happy to answer any questions, hope issue sounds reasonable, thanks!

[BanzaiMan]

The description of this issue does not seem right. Since gradle assemble runs in the install step, the presence of custom script is irrelevant.

In addition, please note that the default behavior of the install step for JVM languages have not changed in 1.5 years: https://github.com/travis-ci/travis-build/blame/master/lib/travis/build/script/shared/jvm.rb#L24-L37 (3 years, if you discount the addition of mvnw support).

I think that the issue about how gradle assemble betrays the assumptions that we make about what the install steps should do has been raised in the past, but I can't locate one now. Maybe it was elsewhere.

[artem-zinnatullin]

I think that the issue about how gradle assemble betrays the assumptions that we make about what the install steps should do has been raised in the past, but I can't locate one now. Maybe it was elsewhere.

Yes, that's accurate, but only part of the issue. Issue description is a little bit off because I thought this behavior was changed recently.

The description of this issue does not seem right. Since gradle assemble runs in the install step, the presence of custom script is irrelevant.

Technically I agree, but if project defines custom script or before_script, default Travis' install behavior can be completely wrong and irrelevant. Not sure users expect Travis to infer anything about the project when they define script section manually. Shouldn't it be in sync with gradle check that gets overridden by script section?

But if you think that presence of script is not enough (and it will be a breaking change anyway), maybe separate travis.yml entry to disable "infer/assume" can be introduced to allow project maintainers precisely control the build and save Travis' resources?

Also, if gradle assemble is install step, then the fact that I had to change before_install to before_script in uber/okbuck#547 to setup environment so Travis' gradle assemble could at least start normally sounds like a bug.

In addition, please note that the default behavior of the install step for JVM languages have not changed in 1.5 years: https://github.com/travis-ci/travis-build/blame/master/lib/travis/build/script/shared/jvm.rb#L24-L37 (3 years, if you discount the addition of mvnw support).

Whoa, surprised I haven't noticed this before and curious how much machine time Travis wasted because of that during 3 years…

I guess, for now the way to avoid this Travis' behavior is to remove language: java and manually install JDK?

Reason why I'm asking is because there is one project that fails the build because of that (assemble task is not expected to be launched, it worked before because project used language: android and I'm trying to switch it to java) and few others where I need to minimize build time.

Great response time btw!

[BanzaiMan]

…if project defines custom script or before_script, default Travis' install behavior can be completely wrong and irrelevant.

I am sorry to say, but this is not a feasible position to take. No other language has this sort of dependence among customizable steps.

I guess, for now the way to avoid this Travis' behavior is to remove language: java and manually install JDK?

Just override the install step.

[artem-zinnatullin]

Just override the install step.

It was that simple, huh!

I am sorry to say, but this is not a feasible position to take. No other language has this sort of dependence among customizable steps.

I didn't say that it would be java only feature, but anyways the core issue is resolved, thank you very much! ❤️

---

Made a PR to improve docs travis-ci/docs-travis-ci-com#1531, again thank you for fast responses and help in resolving the issue!

[ToxicBakery]

Not to bring back a dead thread but the resolution was unclear to me.

install:
- true

Adding that to the .travis.yml will prevent Travis from arbitrarily executing assemble