The cache is not downloaded for the 1.6.2-jdk8 branch from the master branch because it has a different configuration, so its cache cannot be reused. Note the different cache IDs:
-
https://travis-ci.org/HotelsDotCom/bull/builds/617813454#L303:
uploading master/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--jdk-openjdk11.tgz -
https://travis-ci.org/HotelsDotCom/bull/jobs/617815288#L207:
fetching master/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--jdk-openjdk8.tgz
The hash (which is a hash of an amalgam of all configuration-defined envvars (as of this writing)) is the same – but the JDK version is different – resulting in a different cache ID.
Your build needs be able to finish when there’s no cache – since a cache is generally treated as volatile.
If e.g. a build is taking too long, it can be split into stages.
But in your case, the problem is The job exceeded the maximum log length, and has been terminated. – despite a seemmingly short log of only 3282 lines in the job window.
If you look at the raw log for https://travis-ci.org/HotelsDotCom/bull/jobs/617815288, the most of the log is taken up by download progress messages – which you don’t see in the job window because of terminal control characters they use (this is by design, Maven specifically arranges it so that they become invisible once a download is finished). So