heroku deploy tomando muy largo

Tenemos una aplicación bastante grande que está subiendo en heroku ... Es una aplicación que usa browsercms como base, y está construida sobre eso. El Gemfile no es tan grande (no tenemos más gemas que nuestra aplicación promedio) pero por alguna razón, la implementación demora 15 minutos. Compilar y empujando a los activos s3 (a través de assetsync) tarda unos 5 minutos debido a todos los activos, pero los restantes 10 minutos se gasta durante este:heroku deploy tomando muy largo

----> 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

Alguien tiene alguna idea de por qué esta parte lleva tanto tiempo? El bloqueo Gemfile está en el repositorio, y empujó a heroku, y aquí es una esencia de nuestra Gemfile: https://gist.github.com/aa44bbb06eed97736c20

EDIT: Estamos en los carriles 3.2.7

Fuente

2012-09-15 courtsimas

¿Has probado vender tus gemas? Intenta usar 'paquete paquete' para almacenar en caché los archivos' .gem' descargados, y luego ejecuta 'git add. && git commit -m "Vendedor en gemas" para agregarlos a su repositorio Esto debería hacer que la instalación de gemas sea instantánea (suponiendo que sea el cuello de botella). – neersighted

También podría ser la etapa de compilación de activos, en cuyo caso usted querría ejecutar 'rake assets: precompile && git commit -a -m" Recompile assets "' antes de cada despliegue. – neersighted

Vender las gemas ayudó un poco ... y la precompilación local no ahorró tiempo realmente: tomó aproximadamente el mismo tiempo. – courtsimas

Cuando bundler utiliza una joya que tiene un repositorio git descargará todo el repositorio de git para incluir la gema, no solo la rama principal o cualquier rama que sea la rama principal.

Tuvimos este mismo problema con la gema rails_admin de sferik.

Se fuerza ayuda si se especifica una rama específica de este modo:

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

Una forma de saberlo es mirar el tamaño babosa compilado antes y después de realizar un cambio. En nuestro caso, rails_admin fue responsable de aproximadamente 30mb de nuestro tamaño de babosa. Heroku también tiene un límite de tamaño de 100mb de babosas, solo para tu información.

También puede intentar ejecutar el comando bundle pack de esta manera:

bundle pack --all

Esto pondrá todas sus joyas (supuestamente los git también, debido al cambio de --all) en el directorio de proveedores/cache .

Como se indica en este isssue github para el proyecto bundler (se ven al final, donde un tipo heroku responde):

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

Fuente

2012-09-19 19:01:11 jakeonrails

Especificando la rama ahorró un par de megas en el mejor de los casos. Actualmente estamos en un tamaño de babosa de 55 megas (mucho de eso es browsercms). – courtsimas

Dos cosas se aceleraron este proceso. Bundler 1.2.1 parecía ayudar, y turbo sprockets salvó un buen par de minutos. Es tolerable ahora.

Fuente

2012-10-15 19:05:35 courtsimas

Respuesta

Cuestiones relacionadas