Gitlab CI：可以加快“捆绑安装”吗？

我将gitlab.com和CI与共享docker runner一起使用，它在每次提交master时为我的Ruby on Rails项目运行测试。我注意到大约90％的构建时间花费在“捆绑安装”上。是否有可能以某种方式缓存提交之间安装的宝石，以加快“捆绑安装”？Gitlab CI：可以加快“捆绑安装”吗？

UPDATE：

更具体地讲，下面是我的.gitlab-ci.yml的内容。 “测试”脚本的前三行大约需要90％的时间才能使构建运行4-5分钟。

image: ruby:2.2.4 

services: 
    - postgres 

test: 
    script: 
    - apt-get update -qy 
    - apt-get install -y nodejs 
    - bundle install --path /cache 
    - bundle exec rake db:drop db:create db:schema:load RAILS_ENV=test 
    - bundle exec rspec

来源

2016-05-03 andr111

如果你有做了特别的要求，我不知道apt-get的所有的时间，如果不需要在它的命令创建自己的dockerfile 。所以你的基地已经有了这些更新/ nodejs包。如果你想稍后更新，你可以随时更新你的dockerfile。

对于你的宝石，如果你想要它更快，你可以将它们缓存在构建之间。通常这是每个工作和每个分支。见例如这里http://doc.gitlab.com/ee/ci/yaml/README.html#cache

cache: 
    paths: 
    - /cache

我喜欢添加key: "$CI_BUILD_REF_NAME"以便为该特定分支我的文件缓存。请参阅environments以查看您可以使用哪些按键。

来源

2016-05-04 07:24:10

您可以设置BUNDLE_PATH环境变量并将其指向想要安装gems的文件夹。第一次运行bundle install它会安装所有的宝石，因此运行只会检查是否有任何新的宝石，并只安装那些宝石。

注意：这应该是默认行为。检查你的BUNDLE_PATH env var值。它被更改为临时的每个提交文件夹什么的？或者，90％的编译时间正在从rubygems.org下载gem元信息？在这种情况下，您可能需要考虑使用--local标志（但不确定这是CI服务器上的一个好主意）。

Fetching source index for https://rubygems.org/

~~看着你 .gitlab-ci.yml后，我注意到，您的 --path选项丢失 =。我认为这应该是：~~

 - bundle install --path=/cache

来源

2016-05-03 12:56:15 Uzbekjon

你的答案仍然适用于由gitlab.com托管的标准CI跑步者吗？ – andr111

Yeap。我注意到另一个潜在原因。更新了我的答案。 – Uzbekjon

我相信'='并不是每个文档都需要的：http://bundler.io/v1.3/bundle_install.html – andr111

Gitlab CI：可以加快“捆绑安装”吗？

回答

相关问题