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：可以加快「捆綁安裝」嗎？

回答

相關問題