travis+composer repeatedly failing when loading Symfony 2.8.3

Question

• Installing symfony/symfony (v2.8.3) Downloading: 85%PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 6553600 bytes) in phar:///home/travis/.phpenv/versions/5.4.37/bin/composer/src/Composer/Util/RemoteFilesystem.php on line 174 Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 6553600 bytes) in phar:///home/travis/.phpenv/versions/5.4.37/bin/composer/src/Composer/Util/RemoteFilesystem.php on line 174

nearly every build of my project is failing since we updated from Symfony 2.8.2 -> 2.8.3 with this error (out of memory). If I force a rebuild enough times, it eventually passes, so it is obviously not a problem with the project, but with travis or composer or the combination (or Symfony, I suppose). It ONLY fails when trying to load Symfony. It seems like the problem would be widespread, but I cannot find anything on SO or issues at GH.

Does anyone have any suggestions on how to correct the problem?

log from failed build

composer.json file

.travis.yml file

Answer 1

Instead composer update You should call composer install -o (with optimized autloader) on your CI server.

Running composer install will:

• Check if a composer.lock file exists
• If not, perform a composer update to create composer.lock
• If composer.lock exists, install the specified versions from the lock file

Running composer update will:

• Check composer.json
• Determine the latest versions to install based on your version specs - time and memory consuming task
• Install the latest versions
• Update composer.lock to reflect the latest versions installed

Using dependences versions from composer.lock file will give you confidence that Your tests are performed on exactly this same dependencies as you used to development. Even if in your composer.json you use dev-master versions.

If for some reasons you want to run composer update on travis then disabling xdebug before composer install (enable it after if needed for your tests) can improve composer performance. xdebug is enabled by default on travis.

Running Composer console commands while the php extension "xdebug" is loaded reduces speed considerably. This is even the case when all "xdebug" related features are disabled per php.ini flags, but the php extension itself is loaded into the PHP engine. Compared to a cli command run with "xdebug" enabled a speed improvement by a factor of up to 3 is not uncommon.

https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer

Answer 2

I experienced the same issue, the workaround I used was to add the following in before_install :

echo "memory_limit=520M" >> ~/.phpenv/versions/$(phpenv version-name)/etc/conf.d/travis.ini

Coming from this issue on travis. In free plan travis offers 3GB of memory and up to 2 cores available