Yes this fixes the issue but builds take 10-15 mins again.

/cc @phadej Any ideas?

Perhaps we could cache the sandbox in a different place for each separate build?

/cc @hdgarrood

Perhaps we could cache the sandbox in a different place for each separate build?

I thought Travis already did this; I thought there was one cache per entry in the build matrix. I think there's an interface for this inside the web UI? Can you have a look in there and see what it says?

I only see a cache settings page where I can delete caches, and caches are labelled by PR number. It doesn't seem to have anything to do with the particular build.

Ah, ok.

I guess we've gotten away with it so far because packages for each compiler version are kept separately in the sandbox, and this is becoming a problem now because we are trying to install different versions of one package in the same sandbox with the same compiler then?

I think caching separate sandboxes for each build may well be the best way then. Perhaps we could have a sandboxes directory in the root, and we specify a sandbox as a subdirectory of that at the start of the build, where each subdirectory is different based on the particular job? eg, sandboxes/ghc-7.8.4, sandboxes/ghc-7.10.2, sandboxes/stackage-lts-2.2? I think we might be able to achieve this by writing it to a cabal.config file at the start of the build, like we currently do with constraints for Stackage jobs.

Let's see if that does anything.

This seems to be working. Fingers crossed. @hdgarrood Could you please review?

It's obviously getting the paths right, but doesn't seem to be finding the cached files.

Specifically, I always see

Creating a new sandbox at
/home/travis/build/purescript/purescript/sandboxes/7.8.4/none

This all looks ok to me. Sorry, I can't work out what's going on here.

Yeah, it seems to be succeeding now. I think it just needed to warm up or something.

👍 nice you got this figured out

http://docs.travis-ci.com/user/caching/#Fetching-and-storing-caches say

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

Looks like based on your experience, that not per env specification. I'll check travis own issue tracker and make an issue if not there yet. Also better cache inspection tools would be great too.

There was an issue already: travis-ci/travis-ci#4393

I came across this again while working on #1974 and found a slightly hacky solution that does seem to allow us to have separate caches for each entry in the build matrix, by the way: hdgarrood@7e88f3d