WALA/travis/script-gradle

# -*- mode: sh; sh-shell: sh -*-

case "$TRAVIS_OS_NAME" in
  (linux) headless=xvfb-run ;;
  (osx) headless='' ;;
esac

$headless ./gradlew --continue --no-build-cache --stacktrace build javadoc lintGradle
In Travis-CI, test Maven and Gradle separately and concurrently This should help identify cases where the Gradle build only works if it runs before or after a Maven build. It will also help us recognize any Maven regressions accidentally introduced by our Gradle work. 2017-12-19 16:56:41 +00:00			`# -- mode: sh; sh-shell: sh --`

macOS doesn't seem to have "xvfb-run", and may not need it anyway 2018-02-09 02:55:28 +00:00			`case "$TRAVIS_OS_NAME" in`
			`(linux) headless=xvfb-run ;;`
Fix a shellcheck warning when setting a variable to the empty string 2018-03-05 17:56:32 +00:00			`(osx) headless='' ;;`
macOS doesn't seem to have "xvfb-run", and may not need it anyway 2018-02-09 02:55:28 +00:00			`esac`

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-02 02:33:50 +00:00			`$headless ./gradlew --continue --no-build-cache --stacktrace build javadoc lintGradle`