我公司正在使用travis-ci.org（开源软件的免费版本）自动在github上建立对我们存储库的拉取请求。我们有大约20个人全天向同一个仓库提交Pull Requests，每个仓库都建立在一个矩阵中，每个Build包含两个Build Jobs。我们经常注意到，一旦将构建发送到travis，构建就需要花费几分钟 - 有时是几小时。 （症状：构建显示在travis上但计时器没有启动，并且暂时没有控制台输出。）
我认为这是因为travis-ci.org要么是备份的，要么是限制版本。首先
如果是这样，构建如何受到限制？
构建受限制
了解这一点将让我们在travis-ci.org设定的约束条件下优化我们的构建时间（这有望与作为免费用户玩得很好）。
答案 0 :(得分：21)
如果你查看了travis-ci状态页面（http://www.traviscistatus.com/），你会发现＆＃34; Active Linux Build for Open Source项目＆＃34;定期最大化。根据travis私有构建系统的工作原理（一个队列为所有＆＃34;构建作业＆＃34;一次只运行x），我怀疑他们对所有开源构建作业都有一个队列。 / p>
您可以将内置版本拆分为多个作业，每个作业都可以更快完成。当Travis处于轻度使用状态时，它们会并行运行，并且您的构建将很快返回，但是当Travis运行许多其他构建时，您的构建可能只会按顺序运行。
查看您发布的回购邮件中的.travis.yml，您可能会发现通过添加apt和pip缓存（http://docs.travis-ci.com/user/caching/）可以获得良好的性能提升。你还应该考虑改用Travis＆＃39;新的基于容器的基础架构（http://docs.travis-ci.com/user/workers/container-based-infrastructure/）。但是，只有在您能够替换构建中的sudo apt-get命令时，这才有效。
答案 1 :(得分：14)
Travis-CI目前为开源项目提供five concurrent builds，这将计入每个GitHub登录或组织as the Apache Software Foundation discovered的所有存储库。 Travis计算所有项目中的每个“构建作业”并将请求拉向此并发构建的限制。
答案 2 :(得分：3)
在Travis CI上，所有构建都排队，与您的登录名或存储库无关。
此外，如果您查看Travis CI状态历史记录（此处为http://www.traviscistatus.com/history），您会看到他们注意到并调查了您在4月7日和4月8日所描述的问题。他们还在4月9日更新了他们的Build环境（http://docs.travis-ci.com/user/build-environment-updates/2015-04-09/）。在更新期间，要处理的队列正在增长，必须稍后处理。 这种组合可能是您经历的长时间延迟的起源。
我希望这会对你有所帮助。
答案 3 :(得分：1)
我使用Travis供个人使用，而且我每天的构建很少。在构建开始之前我经常注意到几分钟的延迟，这可能是正常的。经过一些研究，我无法找到关于特拉维斯限制的非常好的数字，但他们肯定有一些（source）。这是一个GitHub问题，询问他们是否可以限制每个项目的构建，以便他们不会快速达到用户/公司限制。这意味着有一些限制强制执行。免费版本被描述为“合理使用”，所以我不确定这意味着什么。如果您的构建运行缓慢，我会调查speeding up the build，以便在达到限制之前充分利用它们。
抱歉，我无法提供实际数字，但您应该尽力优化构建。我猜它们可能没有任何硬限制，因为它们可能仍在增长并改变它们的系统可以处理的内容。
我发现了一些数字：
如果/当我把它们罚款时，我会继续寻找限制数字并更新我的答案。