Composer cache on Travis
Ever since the Test lowest, current, and highest possible on Travis post I wanted to dive into caching composers cache on Travis. My experiments started the day after that post.
Travis has a
cache configuration directive that has support for caching entire directories. In our setup we'll cache composer's own cache directory,
$HOME/.composer/cache/files, where it stores dist downloads.
## Cache composer bits
While this generally will speed up your travis builds there are a few caveats
Cloning instead of downloading
One of the things that can happen, depending on your composer.(json|lock), is composer cloning repositories from
Github instead of downloading distfiles. This results in storing the entire repository's into the travis cache. On very simple projects I've seen it go as high as nearly one gigabyte because of certain dev dependencies. While on other projects, that only pulled in dist files, it stays just under 50 megabyte. A way to suggestively force distfiles is the use of
--prefer-dist when installing or updating.
Sometimes when you're making major changes to your composer.json the cache still contains references to the old situation and can distort your test results. This might sound a bit foggy and it is, so a good rule of thumb here is to whenever you remove your local vendor directory you also clear the travis cache.
The speed up results are worth the time setting this up. I've seen projects going from 50 second jobs to 10 seconds because everything is cached. When your doing the lowest, current, and highest thing you'll see slightly slower builds for lowest and highest because those are run though
composer update. You can see the result of one of my packages below:
- 6 February 2017 - Removed
sudoreferences as cache is also up on container infrastructure as well and added
/filesto the path so only dist files are cached.