7

herokuに搭載されているかなり大きなアプリがあります...これは、browsercmsをベースとして使用するアプリであり、その上に構築されています。Gemfileはそれほど大きくはありませんが（平均的なアプリよりも多くのgemはありません）、何らかの理由で、デプロイには15分かかります。アセットのコンパイルとs3へのプッシュ（assetsyncを介して）には、すべてのアセットのために約5分かかりますが、残りの10分はこの間に費やされます。 

----> Heroku receiving push   
-----> Removing .DS_Store files
-----> Ruby/Rails app detected
-----> Using Ruby version: ruby-1.9.3
-----> Installing dependencies using Bundler version 1.2.0
       Running: bundle install --without development:test --path vendor/bundle --binstubs bin/ --deployment

この部分になぜこんなに時間がかかるのか、誰か手がかりがありますか？gemfileロックはリポジトリにあり、herokuにプッシュされます。これが、gemfileの要点です：https ：//gist.github.com/aa44bbb06eed97736c20

編集：私たちはレール3.2.7にいます

4

2 に答える 2

2

バンドラーが git リポジトリを持つ gem を使用する場合、マスター ブランチやメイン ブランチであるブランチだけでなく、gem を含めるために git リポジトリ全体をダウンロードします。

rails_adminsferikの gem でも同じ問題がありました。

次のように特定のブランチを指定すると役立つ場合があります。

gem "browsercms", "3.5.3", git: 'git://github.com/josiahivey/browsercms.git', :branch => 'master'

見分ける方法の 1 つは、変更を行う前後のコンパイル済みスラッグ サイズを確認することです。私たちの場合、rails_admin約 30MB のスラッグ サイズを担当していました。Heroku にも 100 MB のスラッグ サイズ制限があります。参考までに。

次のように bundle pack コマンドを実行することもできます。

bundle pack --all

これにより、すべての gem (おそらく --all スイッチのために git のものも) が vendor/cache ディレクトリに配置されます。

このバンドラー プロジェクトの github issue に示されているように (heroku の担当者が応答する最後を見てください):

https://github.com/carlhuda/bundler/issues/67

于 2012-09-19T19:01:11.243 に答える
0

2 つのことが、このプロセスを高速化しました。Bundler 1.2.1 が役に立ったようで、ターボ スプロケットで数分節約できました。今は許容範囲です。

于 2012-10-15T19:05:35.667 に答える