Closed raboof closed 3 years ago
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
to hopefully fix #46