4

我将 gitlab.com 和 CI 与共享 docker 运行程序一起使用，该运行程序在每次提交到 master 时为我的 Ruby on Rails 项目运行测试。我注意到大约 90% 的构建时间都花在了“捆绑安装”上。是否可以在提交之间以某种方式缓存已安装的 gem 以加快“捆绑安装”？

更新：

更具体地说，下面是我的 .gitlab-ci.yml 的内容。'test' 脚本的前 3 行大约需要 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
4

2 回答 2

1

我不知道您是否对一直执行 apt-get 有特殊要求，如果不需要，请创建您自己的 dockerfile，其中包含这些命令。这样你的基地就已经有了这些更新/nodejs 包。如果您想稍后更新，您可以随时再次更新您的 dockerfile。

对于您的 gem，如果您希望它更快，您也可以在构建之间缓存它们。通常这是每个工作和每个分支。请参阅此处的示例http://doc.gitlab.com/ee/ci/yaml/README.html#cache

cache:
  paths:
  - /cache

我更喜欢添加key: "$CI_BUILD_REF_NAME"，以便为该特定分支缓存我的文件。查看环境以了解您可以更多地使用哪些键。

于 2016-05-04T07:24:10.033 回答
0

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

注意：这应该是默认行为。检查您的BUNDLE_PATH环境变量值。它是否被更改为每个提交文件夹的临时文件夹或其他什么？或者，是否90% 的构建时间都花在了从 ruby​​gems.org 下载 gem 元信息上？在这种情况下，您可能需要考虑使用--local标志（但不确定这在 CI 服务器上是否是一个好主意）。

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

看了你的之后，.gitlab-ci.yml我注意到你的--path选项不见了=。我认为应该是：

      - bundle install --path=/cache
于 2016-05-03T12:56:15.817 回答