I’m a huge advocate of CI and one service in particular called Travis-Ci.
Travis-CI runs a continuous integration platform for both open source and commercial products. In a nutshell: Travis-CI listens for a commit to a Github repository and runs your test suite. Simple as that, no Jenkins required.
At Imagine Easy we happily take advantage of both. :)
So what’s wrong?
For some reason, every other open source project (and probably a lot of closed source projects), use Travis-CI wrong in a way, that it will eventually break your builds.
When exactly? Whenever Travis-CI promotes composer to be a first-class citizen on the platform and attempts to run
composer install automatically for you.
There may be breakage, but there may also be slowdown because by then you may end up with not one, but two
composer install runs before your tests actually run.
Here’s what needs fixing
A lot of projects use composer like so:
before_script: composer install --dev
Here’s what you have to adjust
install: composer install --dev
I had never seen the
install target either. Not consciously at least. And since I don’t do a lot of CI for Ruby projects, I wasn’t exposed to it either. On a Ruby build, Travis-CI will automatically run bundler for you, using said
order of execution
In a nutshell, here are the relevant targets and how the execute:
The future is that Travis-CI will do the following:
before_installwill self-update the
- There is also the rumour of a
composer_opts(or similar) setting so you can provide something like
installtarget, without having to add an
Is any of this your fault? I don’t think so, since the documentation leaves a lot to be desired. Scanning it while writing this blog post, I can’t find a mention of
install target on the pages related to building PHP products.
Long story short: go update your configurations now! ;)