我的公司正在使用travis-ci.org(开源软件的免费版本)在github上自动构建对我们存储库的拉取请求.我们有大约20个人全天向同一个仓库提交Pull Requests,每个仓库都建立在一个矩阵中,每个Build包含两个Build Jobs.我们经常注意到,一旦将构建发送到travis,构建就需要花费几分钟 - 有时是几小时.(症状:构建显示在travis上,但计时器没有启动,并且暂时没有控制台输出.)
我假设发生这种情况是因为travis-ci.org要么是备份的,要么是限制版本.首先
如果是这样,构建如何受到限制?
是否受到限制
知道这一点将让我们在travis-ci.org设置的约束条件下优化我们的构建时间(这有望与作为免费用户玩得很好).
Mat*_*tyB 26
如果你查看了travis-ci状态页面(http://www.traviscistatus.com/),你会发现"Active Linux Build for Open Source projects"会定期出现问题.根据travis私有构建系统的工作原理(所有"构建作业"的单个队列,一次不超过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构建中的命令,那么这只会起作用.
sho*_*yer 17
Travis-CI目前为开源项目提供了五个并发构建,这与Apache Software Foundation发现的每个GitHub登录或组织的所有存储库相对应.Travis计算所有项目中的每个"构建作业"并将请求拉向此并发构建的限制.
| 归档时间: |
|
| 查看次数: |
7735 次 |
| 最近记录: |