加载 Symfony 2.8.3 时，travis+composer 反复失败答案

【问题标题】：travis+composer repeatedly failing when loading Symfony 2.8.3加载 Symfony 2.8.3 时，travis+composer 反复失败
【发布时间】：2016-06-27 08:37:55
【问题描述】：

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

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

有人对如何解决问题有任何建议吗？

log from failed build

composer.json file

.travis.yml file

【问题讨论】：

您应该使用composer install 而不是update，这样它只会加载锁定文件中列出的内容，而不是尝试查看是否有任何更新。
为什么会影响这个问题（内存不足）？
我试过了。你可以在这里看到：travis-ci.org/zikula/core/builds/115512447 - 结果很好。它工作（耶）并且构建得更快（双耶）但我不明白（嘘！）;-)也许你可以解释为什么？
当您使用composer update 时，它会尝试查找composer.json 中每个软件包的最新更新。当您使用composer install 时，它只会安装在您的composer.lock 中注册为已安装的任何内容，这意味着它不会完成所有的工作，例如解决依赖关系和冲突等等。此外，如果您在 travis 测试中使用 composer update，那么您可能不会测试您在本地计算机上的相同设置，因为软件包可能在本地更新和本次更新之间发生了变化。
感谢您提供的扩展信息。

标签： symfony composer-php travis-ci zikula

【解决方案1】：

我遇到了同样的问题，我使用的解决方法是在before_install 中添加以下内容：

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

来自 travis 的 this issue。在免费计划中，travis 提供 3GB 内存和最多 2 个可用内核

【讨论】：

【解决方案2】：

您应该在 CI 服务器上调用 composer install -o（带有优化的自动加载程序）而不是 composer update。

运行 composer install 将：

检查 composer.lock 文件是否存在
如果没有，请执行 composer update 以创建 composer.lock
如果 composer.lock 存在，从锁文件安装指定版本

运行作曲家更新将：

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

使用来自composer.lock 文件的依赖版本将使您确信您的测试是在与您用于开发的完全相同的依赖上执行的。即使在您的 composer.json 中您使用的是 dev-master 版本。

如果由于某些原因您想在 travis 上运行 composer update，那么在 composer install 之前禁用 xdebug（如果需要在您的测试之后启用它）可以提高 composer 的性能。 xdebug 在 travis 上默认启用。

在 php 扩展“xdebug”运行时运行 Composer 控制台命令加载会大大降低速度。甚至当所有每个 php.ini 标志都禁用了“xdebug”相关功能，但 php 扩展本身被加载到 PHP 引擎中。与cli相比使用“xdebug”运行的命令可以将速度提高一倍最多 3 个并不少见。

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

【讨论】：