加载Symfony 2.8.3时,travis + composer反复失败

cra*_*igh 4 symfony travis-ci composer-php zikula

  • 安装symfony/symfony(v2.8.3)下载:85%PHP致命错误:在phar:///home/travis/.phpenv/versions/5.4.37/中,允许的内存大小为1073741824字节(尝试分配6553600字节)第174行上的bin/composer/src/Composer/Util/RemoteFilesystem.php致命错误:phar:///home/travis/.phpenv/versions/5.4中允许的内存大小为1073741824字节(尝试分配6553600字节).第174行/ 37/bin/composer/src/Composer/Util/RemoteFilesystem.php

几乎每个我的项目构建都失败了,因为我们从Symfony 2.8.2 - > 2.8.3更新了这个错误(内存不足).如果我强制重建足够的时间,它最终会通过,所以这显然不是项目的问题,而是使用travis或composer或组合(或Symfony,我想).它只在尝试加载Symfony时失败.看起来这个问题会很普遍,但我找不到任何关于SO或GH的问题.

有没有人对如何纠正这个问题有任何建议?

从失败的构建日志

composer.json文件

.travis.yml文件

Paw*_*zuk 6

相反,composer update您应该composer install -o在CI服务器上调用(使用优化的自动加载器).

运行composer install将:

  • 检查composer.lock文件是否存在
  • 如果没有,请执行编辑器更新以创建composer.lock
  • 如果存在composer.lock,请从锁定文件安装指定的版本

运行作曲家更新将:

  • 检查composer.json
  • 根据您的版本规范确定要安装的最新版本 - 时间和内存消耗任务
  • 安装最新版本
  • 更新composer.lock以反映安装的最新版本

使用composer.lock文件中的依赖项版本可以让您确信您的测试是在与开发时完全相同的依赖项上执行的.即使你composer.json在使用dev-master版本.

如果由于某些原因您希望composer update在travis 上运行,那么在编译器xdebug安装之前禁用(如果测试需要,则启用它)可以提高composer性能.xdebug在travis上默认启用.

加载php扩展"xdebug"时运行Composer控制台命令会大大降低速度.甚至在每个php.ini标志禁用所有"xdebug"相关功能的情况下,但php扩展本身被加载到PHP引擎中.与启用"xdebug"的cli命令相比,速度提升最多3倍并不罕见.

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