Fix #426 - Only cache jar, pom and xml files in .gradle/caches

[LunNova]

Fixes #426.

Same change working for one of my projects - https://travis-ci.org/MinimallyCorrect/DefaultsPlugin/builds/295473198

Testing builds of this project by triggering PR build multiple times and checking that cache isn't changed.

---

Test build 1 - cache changes due to removed .lock files, expected
Test build 2 - has cache changes, should have no cache changes ❌
Test build 3 - cache changes due to removing gradle-worker.jar and ivy.xml
Test build 4 - has no cache changes, should have no cache changes ✔️
Test build 5 - cache changes due to removing lots of shipkit-VERSION.jar from modules-2
Test build 6 - has no cache changes, should have no cache changes✔️

[mockitoguy]

Thank you for working on this!

I'm hesitant to merge it because it adds a lot of complexity to script and the ROI is unknown.

I've looked at recent builds on master:

9:00 5:53 7:32 11:50 7:00 8:50 7:35

Travis CI build for this PR:

7:40 6:40

What are the build times when we turn off the build completely? I'm not too worried about failed downloads from JCenter. If we hit them frequently after turning off the cache we can always bring back the cache :)

Can you show the numbers if we don't use the cache? (or just cache Gradle distros at ~/.gradle/wrapper/*)

Looking forward to hearing from you. Let's close it down. Either by removing the cache or by accepting added complexity and living with it :)

[LunNova]

The "store build cache" action which this avoids takes ~20s for my project. As the total build time is ~120 seconds that's nearly a 20% improvement.

Shipkit's builds take much longer but the cache is also bigger. For example, the first shipkit build with a cache change there records 85.23s uploading the cache.

[mockitoguy]

Fresh datapoints:

• On my local machine, full build with cold Gradle cache is 1m 38s
• Recent build on CI took 6m 48sec. In the log I can see that cache related operations take 33s, 33s, 137s, total: 3m 28s
• I opened a PR #668 to remove cache, let's how long that build will take

Travis cache seems to be providing marginal value. Yet it is an additional complexity that we need to maintain and review periodically. The format of Gradle cache is internal and can change. When it changes, in order to keep our settings effective, we should review and update them. Who is going to remember about it and have time for this?

Performance wise, I don't see enough value from the Travis Cache. If it helps with stability of builds, we can bring the settings back.

@nallar! I appreciate your effort digging into this problem. At this time, we want to avoid additional complexity. I'll close this PR without merging. We would love more contributions from you!!!