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