I've added RUN_DROP_TRAVIS_CACHES_STAGE=true as a public (non secret) ENV VAR available for all branches in the setting on the TravisCI web UI. Then relaunched the (still) failing job.

I think the build plan for this PR is already committed and we won't get a different build with a clean cache unless we send another commit on the PR.

the drop cache uploads a cache:

PR.48/cache--linux-xenial-9632d10a9809d17a5eeb2d7d9cdc036bd97602605eaaebbae154a320ab036321--jdk-default--scala-2.13.1.tgz

... but the failing job fetches another cache:

PR.48/cache--linux-xenial-4a082dd6108cb29866e89deb0edda918357050dffe53206091ab55b2442c3e90--jdk-default--scala-2.13.1.tgz

what's going on here? :/

what's going on here? :/

travis gonna travis.

I'm tempted to merge this, get a clean cache on master and rebase open PRs so they rebuild on a clean cache.

what's going on here? :/

travis gonna travis.

I'm tempted to merge this, get a clean cache on master and rebase open PRs so they rebuild on a clean cache.

can't hurt I guess

can't hurt I guess

it didn't hurt, but didn't help either: also on master the jdk11 check job doesn't pick up the cache emptied by the drop-travis-caches stage...

Ah, https://docs.travis-ci.com/user/caching/:

If a branch does not have its own cache, Travis CI fetches the cache of the repository’s default branch

and:

There is one cache per branch and language version/ compiler version/ JDK version/ Gemfile location/ etc

... so we need to create a separate drop-travis-caches for jdk11 and merge that to master. will do. #49