Composer outdated #1300

damnpoet opened this Issue Aug 2, 2013 · 8 comments


None yet
5 participants

damnpoet commented Aug 2, 2013

Composer is reporting to be over 30 days old when running tests. It recommends to be updated.

$ composer --version

Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/home/travis/.phpenv/versions/5.5.0/bin/composer.phar self-update" to get the latest version.

henrikhodne commented Aug 2, 2013

I believe @joshk has a build environment update in the works for this week or next week, I think this can be included if it isn't already.



henrikhodne commented Aug 25, 2013

@joshk Any chance you could make sure this is done for the next build environment update?


joshk commented Aug 25, 2013

Yep, I just need to plan in the updates.

On 25/08/2013, at 12:15 PM, Henrik Hodne wrote:

@joshk Any chance you could make sure this is done for the next build environment update?

Reply to this email directly or view it on GitHub.

Hello Josh @joshk,
with this small upgrade there is little issue about composer install/update.
Before running units test, most composer repositories needs to launch this install/update command to get required dependencies package and generate the autoload.
2 options are possible --prefer-dist (cache) or --prefer-source (remote repository):

What I've been seeing on build outputs of Travis php workers is that even when we use --prefer-dist packages are not retrieved from cache and and must be cloned remotely. Tell me if I'm wrong ?

Why not making some kind of NFS mount / shared folder at the initialisation of a PHP worker so that versionned packages are "virtually phsyically" present on the server. This could save a huge amount of time for each build.
The same could be applied to the folder where composer.phar is, so that composer itself could always be up-to-date.

Duration for operations on Travis job #10592573:

  • 03 seconds for composer selfupdate
  • 53 seconds for composer update even using --prefer-dist
  • 06 seconds for my tests

On my local machine I've been calculating the amount of time for composer install (BTW if no composer.lock and /vendor exist, update does an install)

07 seconds:

44 seconds:

With a simple ratio, the update time on Travis could be only 8.43 seconds. My example build total duration could be 17.43 seconds instead of 61.00 seconds.
If we do the same for composer itself so there is no need to composer selfupdate, the total build duration could be 14.43 seconds.
Compared to previous 61.00 seconds, this is -76% time necessary of the same build.


joshk commented Aug 25, 2013

Hi @semalead

As Travis does not cache dependencies between test runs --prefer-dist and --prefer-source are going to behave the same.

Providing a shared mount for dependencies is not a good option as a malicious dev could change the cached dependency source code in any number of ways.

I personally recommend installing all deps from fresh as it makes sure you have all the latest versions installed, that deps which have been yanked or removed from composer are not used, and helps identify issues which you may not see when you run tests locally.

Thank you for providing such a detailed summary of the test times, we are definitely looking a ways to improve this and hope to have more information soon :)



ghost commented Aug 30, 2013

+1 please


henrikhodne commented Oct 24, 2013

Composer updates will be included in the next build environment update.

However, since Composer considers itself outdated after 30 days, this is likely to become a recurring problem. If you need the package database to be up to date, I recommend updating it before installing any packages (which is common for other package managers, such as apt-get).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment