What's wrong with composer and your .travis.yml?
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:
language: php
before_script: composer install --dev
script: phpunit
Here's what you have to adjust
language: php
install: composer install --dev
script: phpunit
install
vs. before_script
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 install
target.
order of execution
In a nutshell, here are the relevant targets and how the execute:
before_install
install
before_script
script
The future
The future is that Travis-CI will do the following:
before_install
will self-update thecomposer(.phar)
install
will runcomposer install
- There is also the rumour of a
composer_opts
(or similar) setting so you can provide something like--prefer-source
to theinstall
target, without having to add aninstall
target
Fin
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! ;)
I've started with doctrine/cache and doctrine/dbal, and will make it a habit to send a PR each time I see a configuration which is not what it should be.
Trackbacks
The author does not allow comments to this entry
Comments