WALA/travis
Ben Liblit ba01621de5 Don't use build cache (a.k.a. task output caching) under Travis CI
The performance improvement offered by the build cache is modest when
run by Travis CI.  This is probably because Travis CI does not keep
the cache on any local machine.  Instead, Travis CI uploads the build
cache across a network at the end of each run, then restores the cache
across the network at the start of the next run.  So in many cases
we're simply trading network access to original downloads for network
access to the cache image.

Furthermore, it's probably a better test to perform Travis CI testing
jobs from something closer to a clean slate.  We really want to know
whether everything builds and passes tests correctly starting from
nothing.  We don't want to risk accidentally thinking something would
work simply because we have a cached copy of what it did when it
worked previously.
2018-04-18 11:29:29 -05:00
..
before-cache-gradle "rm" on macOS apparently doesn't understand long ("--foo") flags 2018-04-18 11:29:28 -05:00
before-cache-maven In Travis-CI, test Maven and Gradle separately and concurrently 2018-04-18 11:29:24 -05:00
before-install-gradle In Travis-CI, test Maven and Gradle separately and concurrently 2018-04-18 11:29:24 -05:00
before-install-maven Teach Gradle how to download "/tmp/DroidBench" when needed 2018-04-18 11:29:26 -05:00
install-gradle Don't use build cache (a.k.a. task output caching) under Travis CI 2018-04-18 11:29:29 -05:00
install-maven In Travis-CI, test Maven and Gradle separately and concurrently 2018-04-18 11:29:24 -05:00
script-gradle Don't use build cache (a.k.a. task output caching) under Travis CI 2018-04-18 11:29:29 -05:00
script-maven In Travis-CI, test Maven and Gradle separately and concurrently 2018-04-18 11:29:24 -05:00